Need an official way to exclude parts of the SceneGraph from CSS-Processing

[Tom Schindl]

Hi Jonathan & Kevin,

Let's take CSS-Performance on the side for a moment.

I think the request I have is in itself already legal because there
might be situations where I as a component developer want to rule out
CSS-Processing for a complete SG-Area.

It might be performance (as it is in the case I initially mentioned) but
I think there are other use cases as well. Let's assume I write a
JavaFX-PDF-Viewer (something I really start doing just today) and I want
to avoid someone changing any of the SG-Objects I create (even by accident).

A similar problem we see today with the code-editor control we
developed, unbound CSS-Rules have a good chance to effect the Text-Nodes
who make up our editor and cause performance problems because we have so
many Text-Nodes making up the editor!

Today I have no other option than to programmatically setting all sorts
of properties because then the CSS-Engine then skips them but this
eagerly creates Property-Instances which once more effects memory usage.

I think that I as a control/component developer HAVE TO HAVE the chance
to define that the complete SG below me is managed by me and CSS does
NOT have to be applied to it.

I would propose the following simple "API":

private boolean cssSensitive = true;

public boolean isCssSensitive() {
   return cssSensitive;
}

public void setCssSensitive(boolean cssSensitive) {
   if( this.cssSensitive != cssSensitive ) {
       this.cssSensitive = cssSensitive;
       if( cssSensitive ) {
           reapplyCSS(); // or is applyCSS() not sure
       }
   }
}

private void doProcessCSS() {
   if( ! cssSensitive ) {
     return;
   }
}

I do understand that I'm too late in JDK9 cycle to add such an API but
one could at least dream about such a thing.

Tom

On 24.01.17 00:15, Jonathan Giles wrote:
> There are two different topics here, both of which are near and dear to
> my heart (and also make me feel like I've been doing JavaFX for way too
> long!).
> 
> The specific case of TabPane doing CSS / layout on the content of all
> tabs is something captured here:
> 
> https://bugs.openjdk.java.net/browse/JDK-8092206
> 
> It dates back to 2012 and I remember spending considerable amount of
> effort with my team working through this. As can be seen in some of the
> comments, there were attempts to improve performance (and they were
> really nice), but the outcome was to back it out as we could not change
> the default semantics of loading and doing all work on all tabs. The
> second-to-last comment was a proposal for some API that would specify
> the policy. I really would like to pick this back up for JDK 10, as JDK
> 9 is locked and loaded in this regard. I have retargeted this for JDK 10
> just now.
> 
> As Kevin notes, improving performance is a big push I want to get
> underway for JDK 10. The more general comment made in your email is -
> how can we get better performance out of our critical paths (CSS,
> layout, TableView, etc). That's something we will be actively exploring.
> There are a lot of ideas, some will yield results and some won't. I've
> been running into a few of those dead-ends myself recently as I do
> preliminary investigations.
> 
> If anyone is interested in exploring performance-related topics in
> JavaFX, I've got plenty of areas to explore :-) Ping me off-list and we
> can discuss.
> 
> Unfortunately, again, unless there is some critical oversight these
> discussions and investigations into performance and additional API are
> by default targeted to JDK 10 rather than JDK 9.
> 
> -- Jonathan
> 
> On 20/01/17 11:43 PM, Tom Schindl wrote:
>> Hi,
>>
>> One of the biggest problems when working with JavaFX is that if you
>> reparent a big portion of the SceneGraph is that a full CSS-Pass is
>> applied on all reparented SG-Nodes even if those nodes are currently not
>> visible (eg. because they are part of a TabPane).
>>
>> I general I think it is ok to also applyCSS changes on currently not
>> visible nodes (eg they still have an influence on layout-bounds) but
>> there are situations like the above mentioned example of TabPane that it
>> is unnecessary overhead to apply applyCSS changes on those parts of the
>> SG until they get visible.
>>
>> I would not mind if the CSS-Pass on JavaFX would be as performant as the
>> one from current browsers but unfortunately it isn't so I'd like to
>> discuss the possibility of a API to *temporarily* exclude portions of
>> the SG from CSS-Passes.
>>
>> In JavaFX8 i was able to hack that in by overwriting impl_processCSS in
>> a subclass who changed to doProcessCSS who now is private so my hack
>> does not work anymore.
>>
>> To give you an impression on what performance gains we are talking about
>> just look at the video I recorded -
>> https://tomsondev.bestsolution.at/2016/11/25/improving-minmax-performance-in-e4-on-javafx-applications/
>>
>>
>> Tom
>>
> 


-- 
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck