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

[Jonathan Giles]

Tom,

You can do one better than dream - you can file a JBS issue where we can 
continue to discuss it :-)

-- Jonathan

On 24/01/17 10:21 PM, Tom Schindl wrote:
> 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
>>>
>