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

Tom Schindl tom.schindl at bestsolution.at
Tue Jan 24 21:07:43 UTC 2017


There you go - https://bugs.openjdk.java.net/browse/JDK-8173301

Tom

On 24.01.17 21:47, Jonathan Giles wrote:
> 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
>>>>
>>
> 


-- 
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


More information about the openjfx-dev mailing list