Re: RFR: 8204568: Relative CSS-Attributes don't work all time [v5]

[David Grieve]

On Mon, 8 Mar 2021 07:49:23 GMT, Ambarish Rapte  wrote:

>> Issue is that the size of properties that are relatively(`em`) sized is not 
>> computed correctly when the reference `-fx-font-size` is also specified 
>> relatively and is nested.
>> 
>> Fix is a slight variation of an earlier suggestion in [the 
>> PR](https://github.com/javafxports/openjdk-jfx/pull/94).
>> 
>> Fix is very specific to this scenario and did not show any side effect nor 
>> any test failure.
>> 
>> There are 12 new unit tests added along with fix:
>> - Two tests fail before and pass after this fix. These test verify the 
>> reported failing scenario.
>> sameRelativeFontSizeNestedParentTest
>> relativeFontSizeDeepNestedParentControlTest
>> - Two other tests fail both before and after this fix. They are not related 
>> to the fix. These two tests are ignored. I shall file new JBS issues to 
>> track these cases and update PR with the IDs added to @Ignore.
>> propertySizesRelativeToFontSizeOfControlTest
>> propertySizesRelativeToFontSizeOfParentTest
>> - Other 8 tests are sanity tests which pass both before and after this fix.
>
> Ambarish Rapte has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   minor corrections in comments

Marked as reviewed by dgrieve (Reviewer).

-

PR: https://git.openjdk.java.net/jfx/pull/397

Re: RFR: 8204568: Relative CSS-Attributes don't work all time

[David Grieve]

On Mon, 8 Feb 2021 11:37:35 GMT, Ambarish Rapte  wrote:

> Issue is that the size of properties that are relatively(`em`) sized is not 
> computed correctly when the reference `-fx-font-size` is also specified 
> relatively and is nested.
> 
> Fix is a slight variation of an earlier suggestion in [the 
> PR](https://github.com/javafxports/openjdk-jfx/pull/94).
> 
> Fix is very specific to this scenario and did not show any side effect nor 
> any test failure.
> 
> There are 12 new unit tests added along with fix:
> - Two tests fail before and pass after this fix. These test verify the 
> reported failing scenario.
> sameRelativeFontSizeNestedParentTest
> relativeFontSizeDeepNestedParentControlTest
> - Two other tests fail both before and after this fix. They are not related 
> to the fix. These two tests are ignored. I shall file new JBS issues to track 
> these cases and update PR with the IDs added to @Ignore.
> propertySizesRelativeToFontSizeOfControlTest
> propertySizesRelativeToFontSizeOfParentTest
> - Other 8 tests are sanity tests which pass both before and after this fix.

Marked as reviewed by dgrieve (Reviewer).

-

PR: https://git.openjdk.java.net/jfx/pull/397

RE: [EXTERNAL] Re: JDK-8177635: Optimise CSS lookup resolution

[David Grieve]

I'm looking at a broader issue which is the amount of time spent looking up the 
parent chain to resolve a style. My thought is to push parent state down to 
children as CSS is applied. The state would include pseudoclass, font, and 
styles that might need looking up. 

But I like your change. It looks like a good optimization for the style cache. 
I would let it stand alone. 

-Original Message-
From: openjfx-dev  On Behalf Of Dean Wookey
Sent: Friday, January 29, 2021 1:26 PM
To: openjfx-dev@openjdk.java.net Mailing 
Subject: [EXTERNAL] Re: JDK-8177635: Optimise CSS lookup resolution

Hi David,

We experimented with some changes last year which we've been running. We 
haven't noticed any problems and we do get some good memory and speed 
enhancements.. I've been meaning to clean it up before considering a pull 
request, but since this is a delicate area, I've procrastinated a bit in doing 
that.

Here are the changes 
https://github.com/openjdk/jfx/compare/master...DeanWookey:CleanerPseudoClassEnhancements

I could look at redoing the changes cleaner if you think we've taken the right 
approach, else if not, feel free to incorporate any of the ideas in there in 
what you're doing.

Dean


On Fri, Jan 29, 2021 at 5:11 PM Kevin Rushforth 
wrote:

> Hi David,
>
> That would be great, if a safe fix can be found (I don't need to tell 
> you how fragile the CSS code is when it comes to these sorts of 
> optimizations).
>
> Thanks!
>
> -- Kevin
>
>
> On 1/29/2021 7:02 AM, David Grieve wrote:
> > Anyone mind if I take a crack at 8177635: Optimise CSS lookup resolution?
>
>

JDK-8177635: Optimise CSS lookup resolution

[David Grieve]

Anyone mind if I take a crack at 8177635: Optimise CSS lookup resolution?

RE: CFV: New OpenJFX Committer: Jose Pereda

[David Grieve]

Vote: YES

RE: CFV: New OpenJFX Committer: Jeanette Winzenburg

[David Grieve]

Vote: YES

Re: Community request to test 3D performance

[David Grieve]

Results with NVIDIA Quadro P400:

Without the fix, 1000 quads, average FPS ~7.4
With the fix, 1000 quads, average FPS ~6.1
(this is with Kevin’s pointlighttest.zip)

From: Nir Lisker 
Sent: Thursday, April 23, 2020 5:41 PM
To: David Grieve ; openjfx-dev@openjdk.java.net 
Mailing 
Subject: [EXTERNAL] Re: RE; Community request to test 3D performance

I think so. The test is relatively simple, so it should be worth it. Thanks.

On Fri, Apr 24, 2020 at 12:04 AM David Grieve 
mailto:david.gri...@microsoft.com>> wrote:
I have an NVIDIA Quadro P400. Will that help?

-Original Message-
From: openjfx-dev 
mailto:openjfx-dev-boun...@openjdk.java.net>>
 On Behalf Of Nir Lisker
Sent: Thursday, April 23, 2020 3:55 PM
To: openjfx-dev@openjdk.java.net<mailto:openjfx-dev@openjdk.java.net> Mailing 
mailto:openjfx-dev@openjdk.java.net>>
Subject: [EXTERNAL] Community request to test 3D performance

Hi all,

My PR [1] for adding attenuation for PointLight is pending tests from setups 
with recent NVidia or AMD GPUs. If anyone has such a setup, it would greatly 
help to get tests results from it.

Thanks,
Nir

[1] 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fpull%2F43data=02%7C01%7CDavid.Grieve%40microsoft.com%7C6fb8b89f9d724c990dd608d7e7c0c848%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637232687495430880sdata=OCgL7t6vDim%2F9Lek4htImF8dMZmzAbETAzmoj91T9SE%3Dreserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fpull%2F43=02%7C01%7CDavid.Grieve%40microsoft.com%7C5028a04033b3483afdf008d7e7cf2123%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637232749108715503=8PH%2BZkBX33E2V3K0LuVzLibl1F2OLSLG35a9Cl28WUI%3D=0>

Re: [Rev 03] RFR: 8217472: Add attenuation for PointLight

[David Grieve]

On Sat, 25 Apr 2020 17:07:21 GMT, Kevin Rushforth  wrote:

>> @kevinrushforth
>> Member
>> kevinrushforth commented Apr 18, 2020
>> 
>> I think most of those are good suggestions going forward. As for the 
>> performance drop, the only place we've seen it so
>> far is on graphics accelerators that are a few years old by now.
>> So 50% drop on a 2015 macbook pro is OK ? Do we have numbers on recent 
>> macbook pros ?
>
> If this were an even remotely representative use case, then no, the 
> performance hit would not be OK. The test was
> designed as an artificial "worst-case" stress test: a single mesh with a 
> large number of very large (window-sized)
> quads stacked on top of each other. Any real-world use case won't do this.  
> We should make sure that we aren't seeing
> any significant performance drop when rendering spheres (at a couple 
> different tessellation levels) or boxes.

Results with NVIDIA Quadro P400:

Without the fix, 1000 quads, average FPS ~7.4
With the fix, 1000 quads, average FPS ~6.1

-

PR: https://git.openjdk.java.net/jfx/pull/43

Re: White box / window flicker upon launch

[David Grieve]

It doesn't reproduce for me on windows with JavaFX 11.0.2. 

Whether this is a bug and/or a regression I cannot say. 

-Original Message-
From: Dirk Lemmermann  
Sent: Thursday, April 23, 2020 10:20 AM
To: David Grieve 
Cc: OpenJFX 
Subject: [EXTERNAL] Re: White box / window flicker upon launch

I tried as you suggested. Problem is still there.

> On 23 Apr 2020, at 16:00, David Grieve  wrote:
> 
> Another possible workaround is to call Node#applyCss() before stage.show(). 
> There is an example in the Javadoc for the applyCss() method.
> 
> -Original Message-
> From: openjfx-dev  On Behalf Of 
> Dirk Lemmermann
> Sent: Wednesday, April 22, 2020 1:46 PM
> To: OpenJFX 
> Subject: [EXTERNAL] White box / window flicker upon launch
> 
> Hi everyone,
> 
> is it just me or did something change in the launch behaviour of JavaFX 
> applications? It seems we are back to the old “grey box” bug of Swing where 
> the window would appear first before filling its content. I noticed the same 
> (but white) effect now for my JavaFX apps, especially when running on mobile 
> devices via Gluon. Once I saw it there I paid attention to it and also 
> noticed it when running my desktop apps (on MacOS). I must admit that I am 
> also not certain if it has been different before. Maybe I simply notice it 
> now?
> 
> To verify run this little program. You have to pay close attention but if I 
> am not mistaken then the window first shows up with a white background before 
> showing its content, which is orange.
> 
> Can somebody confirm? If so, I will create a bug ticket.
> 
> Regards,
> 
> Dirk
> 
> 
> import javafx.application.Application; import javafx.scene.Scene; 
> import javafx.scene.layout.VBox; import javafx.stage.Stage;
> 
> public class BugDemo extends Application {
> 
>public void start(Stage stage) {
>VBox root = new VBox();
>root.setStyle("-fx-background-color: orange;");
>Scene scene = new Scene(root, 1000, 800);
>stage.setScene(scene);
>stage.show();
>}
> 
>public static void main(String[] args) {
>launch(args);
>}
> }

RE: White box / window flicker upon launch

[David Grieve]

Another possible workaround is to call Node#applyCss() before stage.show(). 
There is an example in the Javadoc for the applyCss() method.

-Original Message-
From: openjfx-dev  On Behalf Of Dirk 
Lemmermann
Sent: Wednesday, April 22, 2020 1:46 PM
To: OpenJFX 
Subject: [EXTERNAL] White box / window flicker upon launch

Hi everyone,

is it just me or did something change in the launch behaviour of JavaFX 
applications? It seems we are back to the old “grey box” bug of Swing where the 
window would appear first before filling its content. I noticed the same (but 
white) effect now for my JavaFX apps, especially when running on mobile devices 
via Gluon. Once I saw it there I paid attention to it and also noticed it when 
running my desktop apps (on MacOS). I must admit that I am also not certain if 
it has been different before. Maybe I simply notice it now?

To verify run this little program. You have to pay close attention but if I am 
not mistaken then the window first shows up with a white background before 
showing its content, which is orange.

Can somebody confirm? If so, I will create a bug ticket.

Regards,

Dirk


import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.layout.VBox;
import javafx.stage.Stage;

public class BugDemo extends Application {

public void start(Stage stage) {
VBox root = new VBox();
root.setStyle("-fx-background-color: orange;");
Scene scene = new Scene(root, 1000, 800);
stage.setScene(scene);
stage.show();
}

public static void main(String[] args) {
launch(args);
}
}

RE: JavaFX controls have large size on Raspberry Pi

[David Grieve]

The sizes of controls are controlled by CSS styles. Things like borders, 
backgrounds, padding, insets, all of
that defaults to the styles in a stylesheet. Most sizes are 'em' units, meaning 
they are relative to the size 
of the font. JavaFX CSS will use the Font.getDefault() font size if there is no 
font explicitly set in either the 
styles or in the application code. 

I would start by looking at what Font.getDefault().getSize() returns since 
everything should be based off that. 
It could also be an issue with the default stylesheets themselves. 

-Original Message-
From: openjfx-dev  On Behalf Of Alexander 
Scherbatiy
Sent: Monday, April 20, 2020 2:16 PM
To: openjfx-dev@openjdk.java.net
Subject: [EXTERNAL] JavaFX controls have large size on Raspberry Pi

Hello,

I run a simple JavaFX application which shows a button with jdk 14.0.1 on 
Raspberry Pi and the drawn button has large size.

This is because of the algorithm which is used by
PrismFontFactory.getSystemFontSize() method [1] to select a system font size.
If a system is embedded then the font size is calculated as

     int screenDPI = Screen.getMainScreen().getResolutionY();
     systemFontSize = ((float) screenDPI) / 6f; // 12 points

and the system is detected as embedded because the armv6hf architecture is 
defined as embedded in the armv6hf.gradle file [2].

Raspberri Pi can work both with small touch displays and with big monitors. It 
looks like Raspberry Pi should support two modes for font size calculation: one 
for small screens and another for large.

I would like to contribute a fix for this but I do not know how the right fix 
could look like.
Should there be a special screen size so for smaller screens the font is is 
proportional to the screen size and for bigger screens the font size is fixed?
Is there a way to check that used screen is from embedded device?
May be it should be solved in different way?

[1]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fblob%2Fec8608f39576035d41e8e532e9334b979b859543%2Fmodules%2Fjavafx.graphics%2Fsrc%2Fmain%2Fjava%2Fcom%2Fsun%2Fjavafx%2Ffont%2FPrismFontFactory.java%23L1944data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cc0b7e923fe4346bf947608d7e55746f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637230035326172309sdata=rEz4bxNE07aW5f22AXWPRLNffwoIixvNxJopLM%2Bfbi4%3Dreserved=0
[2]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjfx%2Fblob%2Fec8608f39576035d41e8e532e9334b979b859543%2FbuildSrc%2Farmv6hf.gradle%23L182data=02%7C01%7CDavid.Grieve%40microsoft.com%7Cc0b7e923fe4346bf947608d7e55746f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637230035326172309sdata=Fv2sKXwfwuo6JsD0CyeoF6iDmq8rDk5goPCsK31p1Sk%3Dreserved=0

JavaFX application:

import javafx.application.Application;
import javafx.event.ActionEvent;
import javafx.event.EventHandler;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;

public class ButtonFX extends Application {
     public static void main(String[] args) {
     launch(args);
     }

     @Override
     public void start(Stage primaryStage) {
     primaryStage.setTitle("Hello World!");
     Button button = new Button("Hello, World!");

     StackPane root = new StackPane();
     root.getChildren().add(button);
     primaryStage.setScene(new Scene(root, 300, 250));
     primaryStage.show();
     }
}


Thanks,
Alexander.

RE: Is it possible to customise the theme of the Scene Builder itself?

[David Grieve]

This is probably not the right forum for this question. Try a forum like 
stackoverflow. Or reach out to great people at Gluon.

The short answer, however, is that you can play with the CSS styles that make 
up the theme. You'd either need to update the stylesheets in the jar or build 
scene builder yourself. 

-Original Message-
From: openjfx-dev  On Behalf Of Mailing 
User
Sent: Monday, April 20, 2020 3:29 PM
To: openjfx-dev@openjdk.java.net
Subject: [EXTERNAL] Is it possible to customise the theme of the Scene Builder 
itself?

I have downloaded the latest version from a website called Gluon or something. 
The problem is that the default theme lacks contrast. It looks like grey text 
on light grey background. Also the font is too small for me. In File -> 
Preferences, I can see "Scene Builder Theme", but it only has two themes: 
Default and Dark. The Dark theme also lacks contrast. It looks like grey text 
on dark grey background.

Is there any way to change the colours or the font size of Scene Builder 
itself, NOT the scene of my application that I am editing with Scene Builder?

RE: Windows Installation Instructions, All DLL Files Missing

[David Grieve]

Set  -Djava.library.path= C:\Program Files\Java\javafx-sdk-14\bin

For the jlink question, look at jmod. You'll use jmod to bundle up the dll's 
and whatever else you need, then jlink to create the custom runtime.

-Original Message-
From: openjfx-dev  On Behalf Of 
Christopher Miles
Sent: Friday, April 17, 2020 2:56 PM
To: openjfx-dev@openjdk.java.net
Subject: [EXTERNAL] Windows Installation Instructions, All DLL Files Missing

I manage a project[0]  that leverages JavaFX. It's been a while since I've 
worked on this project, almost two years. At that time JavaFX was bundled with 
the Java runtime from Oracle. The few customers I had would simply run the 
application from the bundled launcher and as long as they had Java installed, 
it would work.

It's time for me to add some features to the project, I am now using OpenJDK 
14.0.1 and I installed the OpenJavaFX package and followed the instructions[1] 
from the following URL:

https://openjfx.io/openjfx-docs/#install-javafx

I am on Windows and followed the instructions for that platform. 
Unfortunately, things didn't really work. The error was as follows:

Graphics Device initialization failed for : d3d, sw Error initializing
QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: 
java.lang.RuntimeException: Error initializing QuantumRend erer: no suitable 
pipeline found at 
javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno
wn Source)

I fussed with this and that but nothing made a difference. Eventually I tried 
adding the "bin" directory from the JavaFX distribution to my path. This is the 
entry I added to my global PATH variable:

C:\Program Files\Java\javafx-sdk-14\bin

Is this the right way to do this and, if so, why isn't this included in the 
directions? Is this a Windows specific issue?

Also, what impact does this have on distribution of applications?

Looking at the "Runtime Images" instructions, it looks like the same issues 
will be present. Those instructions use `jlink` to point to the JavaFX 
libraries and the JAVAFX modules (distributed in another package) but also 
leave off references to the DLL files in the "bin" directory. I am worried that 
I will need to have people manually install the OpenJavaFX distribution and add 
the "bin" directory to their path in order to run my application. Please say 
it's not so!

Any help or pointers to additional documentation would be very much 
appreciated! I have made it over the bumps and can now continue development of 
my application, my next concern is distributing it to customers.

--
Miles

[0]: https://github.com/cmiles74/xmltool
[1]: https://openjfx.io/openjfx-docs/#install-javafx

RE: [EXTERNAL] Re: RE: JDK-8177945 : Single cell selection flickers when adding data to TableView

[David Grieve]

That’s possible. I think that’s in the ballpark, at least.

If we could somehow set the cell state before it gets added back into the 
scenegraph, then the cell would be rendered correctly from the start, rather 
than having its state updated halfway through the layout. I haven’t had time to 
circle back on this, but I was looking at and around 
javafx.scene.control.Cell#updateItem and 
javafx.scene.control.Cell#updateSelected

From: Eric Bresie 
Sent: Thursday, March 26, 2020 9:01 AM
To: David Grieve 
Cc: Danny Gonzalez ; 
openjfx-dev@openjdk.java.net
Subject: [EXTERNAL] Re: RE: JDK-8177945 : Single cell selection flickers when 
adding data to TableView

Not sure if this is the cause of some of this but...

I see some similar flags like needsRecreateCells and needsRebuildCells.

In one context (around line 1025) I see a recreateOrRebuild flag based on the 
two.

Is it possible something similar is needed around here to only do something 
once if either is set?

Maybe it’s doing the reset twice as part of recreate and rebuild.

Eric Bresie
ebre...@gmail.com<mailto:ebre...@gmail.com>


On March 10, 2020 at 11:48:27 AM CDT, David Grieve 
mailto:david.gri...@microsoft.com>> wrote:
The flickering is happening because of the way VirtualFlow reuses cells. The 
selected state gets cleared and reset, which is the flicker.
This change fixed the flickering for me. I'm not sure why the index of a cell 
was being set to -1, but the effect of doing so is that when the
cell is pulled out of the pile, it looks like a new cell that has to have its 
index set, selected state set, etc, etc. By commenting out the
updateIndex(-1), VirtualFlow can reuse the cell - setting the index, selected 
state, etc turns into noops (more or less).

Again, there may have been a good reason for setting index to -1 in this 
condition. More investigation needs to be done.

diff --git 
a/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java
 
b/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java
index 728e7c5513..a58859bd05 100644
--- 
a/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java
+++ 
b/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java
@@ -991,9 +991,9 @@ public class VirtualFlow extends 
Region {
lastWidth = -1;
lastHeight = -1;
releaseCell(accumCell);
- for (int i = 0, max = cells.size(); i < max; i++) {
- cells.get(i).updateIndex(-1);
- }
+// for (int i = 0, max = cells.size(); i < max; i++) {
+// cells.get(i).updateIndex(-1);
+// }
addAllToPile();
releaseAllPrivateCells();
} else if (needsReconfigureCells) {


-Original Message-
From: openjfx-dev 
mailto:openjfx-dev-boun...@openjdk.java.net>>
 On Behalf Of
David Grieve
Sent: Friday, March 6, 2020 9:29 AM
To: Danny Gonzalez 
mailto:danny.gonza...@screamingfrog.co.uk>>
Cc: openjfx-dev@openjdk.java.net<mailto:openjfx-dev@openjdk.java.net>
Subject: RE: JDK-8177945 : Single cell selection flickers when adding data to
TableView

This might fix the issue, but I’d like to understand better what the root of the
problem is. My concern is that this fix might cause a performance regression.
I’m using the code in JDK-8177945. I want to look at what TableView does
when it adds a cell. Is there something about the selected state that
changes? Or is this just the CSS implementation recalculating styles and un-
necessarily clearing old values? Some debugging is in order.

From: Danny Gonzalez 
mailto:danny.gonza...@screamingfrog.co.uk>>
Sent: Wednesday, March 4, 2020 4:34 AM
To: David Grieve mailto:david.gri...@microsoft.com>>
Cc: openjfx-dev@openjdk.java.net<mailto:openjfx-dev@openjdk.java.net>
Subject: [EXTERNAL] Re: JDK-8177945 : Single cell selection flickers when
adding data to TableView

Hi David,

Just wanted to add some more information.

The cell selection flashing issue goes away If I put back the following code in
the layout function in Parent.java:

//
// One idiom employed by developers is to, during the layout pass,
// add or remove nodes from the scene. For example, a ScrollPane
// might add scroll bars to itself if it determines during layout
// that it needs them, or a ListView might add cells to itself if
// it determines that it needs to. In such situations we must
// apply the CSS immediately and not add it to the scene's queue
// for deferred action.
//
// Note that we only call processCSS if the flag is update. If the
// flag is DIRTY_BRANCH, then the whatever children need UPDATE
// will be visited during this layout anyway. On the next pulse,
// doCSSPass will clean up the DIRTY_BRANCH nodes.
//
if (cssFlag == CssFlags.UPDATE) {
processCSS();
}

This code was originally added in in the following commit:

commit e76b5755d4d2752037cc95eb75cb2615a740cc30
Author: David Grieve
mailto:dgri...@openjdk.org<mailto:dgri...@openjdk.org%3cmailto:dgri...@openjdk.org>>>
Date: Thu Apr 10 15:40:34 20

Re: JDK-8177945 : Single cell selection flickers when adding data to TableView

[David Grieve]

This fix causes several unit tests to fail.

From: David Grieve 
Sent: Tuesday, March 10, 2020 12:48 PM
To: David Grieve ; Danny Gonzalez 

Cc: openjfx-dev@openjdk.java.net 
Subject: RE: JDK-8177945 : Single cell selection flickers when adding data to 
TableView

The flickering is happening because of the way VirtualFlow reuses cells. The 
selected state gets cleared and reset, which is the flicker.
This change fixed the flickering for me. I'm not sure why the index of a cell 
was being set to -1, but the effect of doing so is that when the
cell is pulled out of the pile, it looks like a new cell that has to have its 
index set, selected state set, etc, etc. By commenting out the
updateIndex(-1), VirtualFlow can reuse the cell - setting the index, selected 
state, etc turns into noops (more or less).

Again, there may have been a good reason for setting index to -1 in this 
condition. More investigation needs to be done.

diff --git 
a/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java
 
b/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java
index 728e7c5513..a58859bd05 100644
--- 
a/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java
+++ 
b/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java
@@ -991,9 +991,9 @@ public class VirtualFlow extends 
Region {
 lastWidth = -1;
 lastHeight = -1;
 releaseCell(accumCell);
-for (int i = 0, max = cells.size(); i < max; i++) {
-cells.get(i).updateIndex(-1);
-}
+//for (int i = 0, max = cells.size(); i < max; i++) {
+//cells.get(i).updateIndex(-1);
+//}
 addAllToPile();
 releaseAllPrivateCells();
 } else if (needsReconfigureCells) {

> -Original Message-
> From: openjfx-dev  On Behalf Of
> David Grieve
> Sent: Friday, March 6, 2020 9:29 AM
> To: Danny Gonzalez 
> Cc: openjfx-dev@openjdk.java.net
> Subject: RE: JDK-8177945 : Single cell selection flickers when adding data to
> TableView
>
> This might fix the issue, but I’d like to understand better what the root of 
> the
> problem is. My concern is that this fix might cause a performance regression.
> I’m using the code in  JDK-8177945. I want to look at what TableView does
> when it adds a cell. Is there something about the selected state that
> changes? Or is this just the CSS implementation recalculating styles and un-
> necessarily clearing old values? Some debugging is in order.
>
> From: Danny Gonzalez 
> Sent: Wednesday, March 4, 2020 4:34 AM
> To: David Grieve 
> Cc: openjfx-dev@openjdk.java.net
> Subject: [EXTERNAL] Re: JDK-8177945 : Single cell selection flickers when
> adding data to TableView
>
> Hi David,
>
> Just wanted to add some more information.
>
> The cell selection flashing issue goes away If I put back the following code 
> in
> the layout function in Parent.java:
>
> //
> // One idiom employed by developers is to, during the layout 
> pass,
> // add or remove nodes from the scene. For example, a 
> ScrollPane
> // might add scroll bars to itself if it determines during 
> layout
> // that it needs them, or a ListView might add cells to 
> itself if
> // it determines that it needs to. In such situations we must
> // apply the CSS immediately and not add it to the scene's 
> queue
> // for deferred action.
> //
> // Note that we only call processCSS if the flag is update. 
> If the
> // flag is DIRTY_BRANCH, then the whatever children need 
> UPDATE
> // will be visited during this layout anyway. On the next 
> pulse,
> // doCSSPass will clean up the DIRTY_BRANCH nodes.
> //
> if (cssFlag == CssFlags.UPDATE) {
>         processCSS();
> }
>
> This code was originally added in in the following commit:
>
> commit e76b5755d4d2752037cc95eb75cb2615a740cc30
> Author: David Grieve
> mailto:dgri...@openjdk.org>>
> Date:   Thu Apr 10 15:40:34 2014 -0400
>
> RT-36559: Some css optimizations: 1 - on impl_reapplyCSS, do not reapply
> css to child nodes if nothing has changed. 2 - on applyCss, only look for
> ancestor node with css state = UPDATE. 3 - only recalculate checksum of css
> file if the file has been removed from a scene or parent
>
>
> It was reverted out in this commit:
>
> commit 05afad6b528e871d607b76aea2642cf788b417fe
> Author: David Grieve
> mailto:dgri...@openjdk.org>>
> Dat

RE: JDK-8177945 : Single cell selection flickers when adding data to TableView

[David Grieve]

The flickering is happening because of the way VirtualFlow reuses cells. The 
selected state gets cleared and reset, which is the flicker. 
This change fixed the flickering for me. I'm not sure why the index of a cell 
was being set to -1, but the effect of doing so is that when the
cell is pulled out of the pile, it looks like a new cell that has to have its 
index set, selected state set, etc, etc. By commenting out the 
updateIndex(-1), VirtualFlow can reuse the cell - setting the index, selected 
state, etc turns into noops (more or less). 

Again, there may have been a good reason for setting index to -1 in this 
condition. More investigation needs to be done. 

diff --git 
a/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java
 
b/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java
index 728e7c5513..a58859bd05 100644
--- 
a/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java
+++ 
b/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java
@@ -991,9 +991,9 @@ public class VirtualFlow extends 
Region {
 lastWidth = -1;
 lastHeight = -1;
 releaseCell(accumCell);
-for (int i = 0, max = cells.size(); i < max; i++) {
-cells.get(i).updateIndex(-1);
-}
+//for (int i = 0, max = cells.size(); i < max; i++) {
+//cells.get(i).updateIndex(-1);
+//}
 addAllToPile();
 releaseAllPrivateCells();
 } else if (needsReconfigureCells) {

> -Original Message-
> From: openjfx-dev  On Behalf Of
> David Grieve
> Sent: Friday, March 6, 2020 9:29 AM
> To: Danny Gonzalez 
> Cc: openjfx-dev@openjdk.java.net
> Subject: RE: JDK-8177945 : Single cell selection flickers when adding data to
> TableView
> 
> This might fix the issue, but I’d like to understand better what the root of 
> the
> problem is. My concern is that this fix might cause a performance regression.
> I’m using the code in  JDK-8177945. I want to look at what TableView does
> when it adds a cell. Is there something about the selected state that
> changes? Or is this just the CSS implementation recalculating styles and un-
> necessarily clearing old values? Some debugging is in order.
> 
> From: Danny Gonzalez 
> Sent: Wednesday, March 4, 2020 4:34 AM
> To: David Grieve 
> Cc: openjfx-dev@openjdk.java.net
> Subject: [EXTERNAL] Re: JDK-8177945 : Single cell selection flickers when
> adding data to TableView
> 
> Hi David,
> 
> Just wanted to add some more information.
> 
> The cell selection flashing issue goes away If I put back the following code 
> in
> the layout function in Parent.java:
> 
> //
> // One idiom employed by developers is to, during the layout 
> pass,
> // add or remove nodes from the scene. For example, a 
> ScrollPane
> // might add scroll bars to itself if it determines during 
> layout
> // that it needs them, or a ListView might add cells to 
> itself if
> // it determines that it needs to. In such situations we must
> // apply the CSS immediately and not add it to the scene's 
> queue
> // for deferred action.
> //
> // Note that we only call processCSS if the flag is update. 
> If the
> // flag is DIRTY_BRANCH, then the whatever children need 
> UPDATE
> // will be visited during this layout anyway. On the next 
> pulse,
> // doCSSPass will clean up the DIRTY_BRANCH nodes.
> //
> if (cssFlag == CssFlags.UPDATE) {
>     processCSS();
> }
> 
> This code was originally added in in the following commit:
> 
> commit e76b5755d4d2752037cc95eb75cb2615a740cc30
> Author: David Grieve
> mailto:dgri...@openjdk.org>>
> Date:   Thu Apr 10 15:40:34 2014 -0400
> 
> RT-36559: Some css optimizations: 1 - on impl_reapplyCSS, do not reapply
> css to child nodes if nothing has changed. 2 - on applyCss, only look for
> ancestor node with css state = UPDATE. 3 - only recalculate checksum of css
> file if the file has been removed from a scene or parent
> 
> 
> It was reverted out in this commit:
> 
> commit 05afad6b528e871d607b76aea2642cf788b417fe
> Author: David Grieve
> mailto:dgri...@openjdk.org>>
> Date:   Tue Apr 15 11:51:38 2014 -0400
> 
> RT-36672: move code to process css during layout back to impl_reapplyCSS,
> which is where it was priort to RT-36559
> 
> 
> 
> 
> This was the point at which the cell selection flashing appeared.
> 
&

RE: JDK-8177945 : Single cell selection flickers when adding data to TableView

[David Grieve]

This might fix the issue, but I’d like to understand better what the root of 
the problem is. My concern is that this fix might cause a performance 
regression.
I’m using the code in  JDK-8177945. I want to look at what TableView does when 
it adds a cell. Is there something about the selected state that changes? Or is 
this just the CSS implementation recalculating styles and un-necessarily 
clearing old values? Some debugging is in order.

From: Danny Gonzalez 
Sent: Wednesday, March 4, 2020 4:34 AM
To: David Grieve 
Cc: openjfx-dev@openjdk.java.net
Subject: [EXTERNAL] Re: JDK-8177945 : Single cell selection flickers when 
adding data to TableView

Hi David,

Just wanted to add some more information.

The cell selection flashing issue goes away If I put back the following code in 
the layout function in Parent.java:

//
// One idiom employed by developers is to, during the layout 
pass,
// add or remove nodes from the scene. For example, a ScrollPane
// might add scroll bars to itself if it determines during 
layout
// that it needs them, or a ListView might add cells to itself 
if
// it determines that it needs to. In such situations we must
// apply the CSS immediately and not add it to the scene's queue
// for deferred action.
//
// Note that we only call processCSS if the flag is update. If 
the
// flag is DIRTY_BRANCH, then the whatever children need UPDATE
// will be visited during this layout anyway. On the next pulse,
// doCSSPass will clean up the DIRTY_BRANCH nodes.
//
if (cssFlag == CssFlags.UPDATE) {
processCSS();
}

This code was originally added in in the following commit:

commit e76b5755d4d2752037cc95eb75cb2615a740cc30
Author: David Grieve mailto:dgri...@openjdk.org>>
Date:   Thu Apr 10 15:40:34 2014 -0400

RT-36559: Some css optimizations: 1 - on impl_reapplyCSS, do not reapply 
css to child nodes if nothing has changed. 2 - on applyCss, only look for 
ancestor node with css state = UPDATE. 3 - only recalculate checksum of css 
file if the file has been removed from a scene or parent


It was reverted out in this commit:

commit 05afad6b528e871d607b76aea2642cf788b417fe
Author: David Grieve mailto:dgri...@openjdk.org>>
Date:   Tue Apr 15 11:51:38 2014 -0400

RT-36672: move code to process css during layout back to impl_reapplyCSS, 
which is where it was priort to RT-36559




This was the point at which the cell selection flashing appeared.


Thanks


Danny



On 3 Mar 2020, at 16:50, David Grieve 
mailto:david.gri...@microsoft.com>> wrote:

The importance of 05afad6 Is there in the commit itself:

+//
+// One idiom employed by developers is to, during the layout pass,
+// add or remove nodes from the scene. For example, a ScrollPane
+// might add scroll bars to itself if it determines during layout
+// that it needs them, or a ListView might add cells to itself if
+// it determines that it needs to. In such situations we must
+// apply the CSS immediately and not add it to the scene's queue
+// for deferred action.
+

If you revert 05afad6, you'll break this.

This is the first time I've become aware of this flickering issue. I'll have to 
look at it.
I wonder if the fix for 
https://bugs.openjdk.java.net/browse/JDK-8193445<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8193445=02%7C01%7CDavid.Grieve%40microsoft.com%7C9148c860ff524a32ac3208d7c01f2523%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637189112753556661=mZrjldSw%2Fjbd0ita58XMU%2BaKM2GlvObq3aaQmQb5Poc%3D=0>
 has any impact on this.


-Original Message-
From: openjfx-dev 
mailto:openjfx-dev-boun...@openjdk.java.net>>
 On Behalf Of
Danny Gonzalez
Sent: Tuesday, March 3, 2020 11:14 AM
To: openjfx-dev@openjdk.java.net<mailto:openjfx-dev@openjdk.java.net>
Subject: [EXTERNAL] JDK-8177945 : Single cell selection flickers when adding
data to TableView


There is currently an open bug to do with the issue of selection flickering
when using single cell selection and when adding data to a TableView.
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs
.java.com%2Fbugdatabase%2Fview_bug.do%3Fbug_id%3D8177945da
ta=02%7C01%7Cdavid.grieve%40microsoft.com%7C91a16d9ab05340719f3008
d7bf8e3410%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63718848
9816399816sdata=wdPRh3VnN%2BfJw%2BatKOyBi9%2Ba2%2FidMJJb
8AwcRXVrfLo%3Dreserved=0

This bug seems to be low priority because it hasn’t been looked at since I
submitted it at the start of 2017.

This is quite a major issue for us so I have narrowed down when the issue
was first introduced.

Here is the changeset:

commit 05afad6b528e871d607b76aea

RE: JDK-8177945 : Single cell selection flickers when adding data to TableView

[David Grieve]

The importance of 05afad6 Is there in the commit itself: 

+//
+// One idiom employed by developers is to, during the layout pass,
+// add or remove nodes from the scene. For example, a ScrollPane
+// might add scroll bars to itself if it determines during layout
+// that it needs them, or a ListView might add cells to itself if
+// it determines that it needs to. In such situations we must
+// apply the CSS immediately and not add it to the scene's queue
+// for deferred action.
+

If you revert 05afad6, you'll break this. 

This is the first time I've become aware of this flickering issue. I'll have to 
look at it. 
I wonder if the fix for https://bugs.openjdk.java.net/browse/JDK-8193445 has 
any impact on this.  

> -Original Message-
> From: openjfx-dev  On Behalf Of
> Danny Gonzalez
> Sent: Tuesday, March 3, 2020 11:14 AM
> To: openjfx-dev@openjdk.java.net
> Subject: [EXTERNAL] JDK-8177945 : Single cell selection flickers when adding
> data to TableView
> 
> 
> There is currently an open bug to do with the issue of selection flickering
> when using single cell selection and when adding data to a TableView.
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs
> .java.com%2Fbugdatabase%2Fview_bug.do%3Fbug_id%3D8177945da
> ta=02%7C01%7Cdavid.grieve%40microsoft.com%7C91a16d9ab05340719f3008
> d7bf8e3410%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63718848
> 9816399816sdata=wdPRh3VnN%2BfJw%2BatKOyBi9%2Ba2%2FidMJJb
> 8AwcRXVrfLo%3Dreserved=0
> 
> This bug seems to be low priority because it hasn’t been looked at since I
> submitted it at the start of 2017.
> 
> This is quite a major issue for us so I have narrowed down when the issue
> was first introduced.
> 
> Here is the changeset:
> 
> commit 05afad6b528e871d607b76aea2642cf788b417fe
> Author: David Grieve
> mailto:dgri...@openjdk.org>>
> Date:   Tue Apr 15 11:51:38 2014 -0400
> 
> RT-36672: move code to process css during layout back to impl_reapplyCSS,
> which is where it was priort to RT-36559
> 
> 
> I can’t search the bug database for this bug ID as I believe it was submitted
> when a previous bug tracking system was in use.
> 
> Does anyone have any knowledge as to why this fix was needed and what
> the repercussions would be if I reverted it out for our local OpenJFX build.
> 
> Alternatively I would be glad to receive any suggestions of how to fix the
> flickering issue if this changeset is important to leave in.
> 
> Thanks
> 
> Danny

RE: [EXTERNAL] Explanation of different scaling factors anywhere?

[David Grieve]

Wouldn't this just be a scale transform? 

> -Original Message-
> From: openjfx-dev  On Behalf Of
> Mike Hearn
> Sent: Monday, January 27, 2020 11:00 AM
> To: openjfx-dev@openjdk.java.net
> Subject: [EXTERNAL] Explanation of different scaling factors anywhere?
> 
> Hello,
> 
> A feature I often miss when using non-web GUIs is support for browser style
> zooming. In JavaFX it is quite easy to specify all font sizes in terms of 
> "ems",
> relative sizes ("largest") or percentages and then adjust the base font size 
> on a
> root node inside key handlers. This works OK but doesn't do much for images
> or other controls, and of course most JavaFX GUI code specifies sizes in terms
> of pixels.
> 
> There are various scaling factors applied to pixel sizes. There is the 
> per-node
> scaling transform, but this doesn't affect layout so isn't comparable to what
> browsers do. There's a per-screen DPI, there's a "platform scale", there's a
> "render scale" and then there's a "ui scale".
> These seem related to hidpi/retina support and are all internal (for the
> purposes of this question I'm happy to modify JavaFX itself).
> 
> Render scale seems to affect resolution without affecting positions or layout,
> so that's not quite what I want. UI scale sounds promising but isn't
> documented and I couldn't quite figure it out by reading the code, though I
> could just fiddle with it and see what happens.
> 
> It feels like someone probably explored this before now. Is there a way to
> effectively expand the size of every node without altering the size of the
> containing viewport, to get browser-style layout affecting  zoom?  If not, has
> anyone explored the complexity of the modifications required?
> 
> thanks,
> -mike

Re: [Rev 01] RFR: 8237469: CssStyleHelper reuse check fixed

[David Grieve]

On Wed, 22 Jan 2020 17:03:49 GMT, Dean Wookey  wrote:

>> Everything passes with the fix and 5 of the new tests fail without the fix.
>> 
>> removingThenAddingNodeToDifferentBranchGetsNewFontStyleTest
>> movingBranchToDifferentBranchGetsNewCssVariableTest
>> removingThenAddingNodeToDifferentBranchGetsCorrectInheritedValue
>> removingThenAddingNodeToDifferentBranchGetsIneritableStyle
>> movingNodeToDifferentBranchGetsNewFontStyleTest
>> 
>> I doubt this will cause a significant performance decrease. I think it's 
>> worth it for correctness. The only other thing is that I kept the fix to the 
>> minimum, but technically canReuseHelper now has a side effect. I could try 
>> rewrite some things if necessary, or maybe rename the method? Else leave it 
>> as is?
>> 
>> Originally introduced here: 
>> https://bugs.openjdk.java.net/browse/JDK-8090462/ 
>> https://github.com/openjdk/jfx/commit/834b0d05e7a2a8351403ec4a121eab312d80fd24#diff-9ec098280fa1aeed53c70243347e76ab
> 
> The pull request has been updated with 1 additional commit.

Marked as reviewed by dgrieve (Reviewer).

-

PR: https://git.openjdk.java.net/jfx/pull/87

Re: RFR: 8237469: CssStyleHelper reuse check fixed

[David Grieve]

On Fri, 17 Jan 2020 14:09:54 GMT, Dean Wookey  wrote:

> Everything passes with the fix and 5 of the new tests fail without the fix.
> 
> removingThenAddingNodeToDifferentBranchGetsNewFontStyleTest
> movingBranchToDifferentBranchGetsNewCssVariableTest
> removingThenAddingNodeToDifferentBranchGetsCorrectInheritedValue
> removingThenAddingNodeToDifferentBranchGetsIneritableStyle
> movingNodeToDifferentBranchGetsNewFontStyleTest
> 
> I doubt this will cause a significant performance decrease. I think it's 
> worth it for correctness. The only other thing is that I kept the fix to the 
> minimum, but technically canReuseHelper now has a side effect. I could try 
> rewrite some things if necessary, or maybe rename the method? Else leave it 
> as is?
> 
> Originally introduced here: https://bugs.openjdk.java.net/browse/JDK-8090462/ 
> https://github.com/openjdk/jfx/commit/834b0d05e7a2a8351403ec4a121eab312d80fd24#diff-9ec098280fa1aeed53c70243347e76ab

Changes requested by dgrieve (Reviewer).

modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 134:

> 133: node.styleHelper.triggerStates.addAll(triggerStates[0]);
> 134: 
> 135: updateParentTriggerStates(node, depth, triggerStates);

In canReuseStyleHelper, there is this check
   // If the style maps are the same instance, we can re-use the current 
styleHelper if the cacheContainer is null.
// Under this condition, there are no styles for this node _and_ no 
styles inherit.
if (node.styleHelper.cacheContainer == null) {
return true;
}
And later in the same function is a check for (parent == null) that returns 
true. In both cases, firstStyleableAncestor will still point to the old 
first-styleable ancestor.

-

PR: https://git.openjdk.java.net/jfx/pull/87

RE: [EXTERNAL] CssStyleHelper canReuseStyleHelper

[David Grieve]

I'd create a scenegraph 

 R 
 .-+-.
 A   B
   .+.
   CD

Where C and D are Labels. Then I'd set a font style on A and a different font 
style on B. 
C and D should pick up the font style of A. Then move D to B and see if it 
still has A's 
font style. 

It may be necessary to have a more deeply nested scene graph. 

The potential issue is that the node that got moved could pick up the old set 
of styles
if the style helper is not renewed. 

Ultimately, canReuseStyleHelper will return false if the set of styles for the 
new parent (line 110 or so in CssStyleHelper.java) are different. 

> -Original Message-
> From: openjfx-dev  On Behalf Of
> Dean Wookey
> Sent: Thursday, January 16, 2020 11:34 AM
> To: openjfx-dev@openjdk.java.net Mailing  d...@openjdk.java.net>; David Grieve 
> Cc: aghai...@openjdk.org
> Subject: [EXTERNAL] CssStyleHelper canReuseStyleHelper
> 
> Hi Ajit, David,
> 
> I came accross a potential issue introduced by JDK-8090462 (
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs
> .openjdk.java.net%2Fbrowse%2FJDK-
> 8090462data=02%7C01%7Cdavid.grieve%40microsoft.com%7C235930d
> fab7f4f7f15ba08d79aa21774%7C72f988bf86f141af91ab2d7cd011db47%7C1%7
> C0%7C637147893881930150sdata=awsMTPYkp7GmSrYsoy9I6M%2F6uj
> X7thgZhBVY9UKcjpU%3Dreserved=0), (
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fopenjdk%2Fjfx%2Fcommit%2F834b0d05e7a2a8351403ec4a121ea
> b312d80fd24%23diff-
> 9ec098280fa1aeed53c70243347e76abdata=02%7C01%7Cdavid.grieve%
> 40microsoft.com%7C235930dfab7f4f7f15ba08d79aa21774%7C72f988bf86f141
> af91ab2d7cd011db47%7C1%7C0%7C637147893881930150sdata=ZhWS
> dmlJ9rLzIkqnohWTacJKPb8FNrG5yApF0fwP8g4%3Dreserved=0).
> The issue is in the canReuseStyleHelper method. canReuseStyleHelper is
> called as a result of changes to the scene graph and for other reasons. The
> original code found the parent helper in the following way:
> 
> Styleable parent = node.getStyleableParent();
> while (parent != null) {
> if (parent instanceof Node) {
> parentHelper = ((Node) parent).styleHelper;
> if (parentHelper != null) break;
> }
> parent = parent.getStyleableParent();
> }
> 
> This gets the parent helper for the new parent of the node. The code now (
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fopenjdk%2Fjfx%2Fblob%2F20325e1c3ec4c4e81af74d3d43bf3a803
> dbe1a51%2Fmodules%2Fjavafx.graphics%2Fsrc%2Fmain%2Fjava%2Fjavafx%
> 2Fscene%2FCssStyleHelper.java%23L322data=02%7C01%7Cdavid.griev
> e%40microsoft.com%7C235930dfab7f4f7f15ba08d79aa21774%7C72f988bf86f
> 141af91ab2d7cd011db47%7C1%7C0%7C637147893881930150sdata=nJR
> 3ocKaIsf6HWNjHtseEbqLbEvbW7%2FzQS1B%2F39GVyI%3Dreserved=
> 0
> ):
> 
> CssStyleHelper parentHelper =
> getStyleHelper(node.styleHelper.firstStyleableAncestor);
> 
> gets the helper of the previous parent of the node since
> firstStyleableAncestor hasn't been updated to reflect the current state of the
> scene graph yet. This means if you move a node, it could keep its
> CssStyleHelper even if it's under completely new parents.
> 
> I'm not sure if this is actually causing any problems. It would be helpful if 
> I
> knew the kind of things that could go wrong if you reuse a style helper so
> that I could design a test that highlighted the issue.
> 
> Can you perhaps think of cases where this could go badly?
> 
> Dean

RE: [EXTERNAL] Memory leak in JavaFX 8 when changing skins

[David Grieve]

Possible workarounds would be to use Control.setSkin instead of -fx-skin, or to 
bind the skin property after it has been set to something other than the 
default.  CSS should not mess with a bound property.

> -Original Message-
> From: openjfx-dev  On Behalf Of
> Adam Granger
> Sent: Thursday, January 9, 2020 3:04 AM
> To: openjfx-dev@openjdk.java.net
> Subject: [EXTERNAL] Memory leak in JavaFX 8 when changing skins
> 
> 
> Greetings,
> 
> I realise this is now legacy for most people but we still widely use JavaFX 8.
> 
> I appear to have discovered a memory leak when skin is changed
> 
> The constructor
> com.sun.javafx.scene.control.skin.BehaviorSkinBase.BehaviorSkinBase
> adds an event listener
> 
>    control.addEventHandler(ContextMenuEvent.CONTEXT_MENU_REQUESTE
> D,
> contextMenuHandler);
> 
> However this is never removed in the dispose() which prevents garbage
> collection of the previous skin.
> 
> This problem is amplified by fact JavaFX appears to reload skins unnecessarily
> in a complex use case involving JFXPanel  - I've as-yet been unable to
> produce a SSCCE for this
> 
> What I've discovered so far
>  - CSS is reprocessed
> 
>  - javafx.scene.CssStyleHelper.canReuseStyleHelper(Node, StyleMap)
> returns false
>  - node.styleHelper.resetToInitialValues(node); is called which then causes
> the "stock" skin load
>  - custom skin (-fx-skin in our application CSS) is then loaded
> 
>  - stock skin cannot be GC'd and neither can our custom skin
>  - appears to affect any subclass of BehaviorSkinBase
> 
> Please could you confirm my analysis of this problem and suggest any
> workarounds?
> 
> Regards,
> 
> Adam

Re: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator

[David Grieve]

On Thu, 19 Dec 2019 16:16:28 GMT, Kevin Rushforth  wrote:

>> probably not  invented so often - just c'd from searches of occurances of 
>> System.gc ;-)
> 
> Yes, exactly.
> 
> @FlorianKirmaier Proposing to add test class to the test infrastructure would 
> be a reasonable alternative to pulling it in as a third-party dependency. I 
> recommend separating it out into its own enhancement, with a separate JBS 
> issue. I see that it has a dependency on the `jdk.management` module. As long 
> as that dependency only surfaces as a test dependency, that won't be a 
> problem. It would be nice if it were available to all modules, meaning that 
> putting it somewhere in `javafx.base` would be good.

I would urge caution about incorporating JMemoryBuddy without seeking out 
advice from GC experts. I have my doubts that it will work reliably given its 
reliance on System.gc(). (Opinion is my own, not my employer's).

-

PR: https://git.openjdk.java.net/jfx/pull/71

Re: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator

[David Grieve]

Github failed me. My 'remove' comment was applied to the System.out.println, 
not the assert. 

> -Original Message-
> From: openjfx-dev  On Behalf Of
> David Grieve
> Sent: Thursday, December 19, 2019 2:29 PM
> To: openjfx-dev@openjdk.java.net
> Subject: [EXTERNAL] Re: [Rev 01] RFR: 8236259: MemoryLeak in
> ProgressIndicator
> 
> On Thu, 19 Dec 2019 19:28:34 GMT, Florian Kirmaier
>  wrote:
> 
> >> Hi everyone,
> >>
> >> ticket:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs
> .openjdk.java.net%2Fbrowse%2FJDK-
> 8236259data=02%7C01%7CDavid.Grieve%40microsoft.com%7C856e05
> 0ee1bf484a7a7008d784b9dde4%7C72f988bf86f141af91ab2d7cd011db47%7C1
> %7C0%7C637123806135627853sdata=yMuZMaBg7UmJEWzn8AGI6K8f5
> aRmFclOi4nov%2BLas%2BM%3Dreserved=0
> >>
> >> The fix itself is quite straight forward.
> >> It basically just removed the listener which causes the leak.
> >>
> >> The unit-test for the fix is a bit more complicated.
> >>
> >> I added a library JMemoryBuddy
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2FSandec%2FJMemoryBuddydata=02%7C01%7CDavid.Griev
> e%40microsoft.com%7C856e050ee1bf484a7a7008d784b9dde4%7C72f988bf8
> 6f141af91ab2d7cd011db47%7C1%7C0%7C637123806135627853sdata=6
> a1cOZEa9Ah%2F47NyvrRetz9YZyTgXhoJ1b13re8SZw8%3Dreserved=0
> (written by myself), which simplifies testing for memory leaks.
> >> I think there are many places in the JavaFX-codebase that could highly
> benefit from this library.
> >> It could also simplify many of the already existing unit tests.
> >> It makes testing for memory-leaks readably and reliable.
> >> It would also be possible to just copy the code of the library into the
> JavaFX-codebase.
> >> It only contains a single class.
> >>
> >> I also had to make a method public, to write the test. I'm open to ideas,
> how I could solve it differently.
> >
> > The pull request has been updated with 1 additional commit.
> 
> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/Progr
> essIndicatorSkinTest.java line 106:
> 
> > 105: Node detIndicator = 
> > indicator.getChildrenUnmodifiable().get(0);
> > 106: 
> > System.out.println(detIndicator.getClass().getSimpleName());
> > 107: checker.assertCollectable(detIndicator);
> 
> remove
> 
> -
> 
> PR:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.o
> penjdk.java.net%2Fjfx%2Fpull%2F71data=02%7C01%7CDavid.Grieve%
> 40microsoft.com%7C856e050ee1bf484a7a7008d784b9dde4%7C72f988bf86f1
> 41af91ab2d7cd011db47%7C1%7C0%7C637123806135627853sdata=ATF
> nmAXAw0x0ENGrqp%2Fde8fEuIg7mrQrYZmXn4gLnug%3Dreserved=0

Re: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator

[David Grieve]

On Thu, 19 Dec 2019 19:28:34 GMT, Florian Kirmaier  
wrote:

>> Hi everyone,
>> 
>> ticket: https://bugs.openjdk.java.net/browse/JDK-8236259
>> 
>> The fix itself is quite straight forward.
>> It basically just removed the listener which causes the leak.
>> 
>> The unit-test for the fix is a bit more complicated.
>> 
>> I added a library JMemoryBuddy https://github.com/Sandec/JMemoryBuddy 
>> (written by myself), which simplifies testing for memory leaks.
>> I think there are many places in the JavaFX-codebase that could highly 
>> benefit from this library.
>> It could also simplify many of the already existing unit tests.
>> It makes testing for memory-leaks readably and reliable. 
>> It would also be possible to just copy the code of the library into the 
>> JavaFX-codebase. 
>> It only contains a single class.
>> 
>> I also had to make a method public, to write the test. I'm open to ideas, 
>> how I could solve it differently.
> 
> The pull request has been updated with 1 additional commit.

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/ProgressIndicatorSkinTest.java
 line 106:

> 105: Node detIndicator = 
> indicator.getChildrenUnmodifiable().get(0);
> 106: System.out.println(detIndicator.getClass().getSimpleName());
> 107: checker.assertCollectable(detIndicator);

remove

-

PR: https://git.openjdk.java.net/jfx/pull/71

Re: apps/toys HelloTextFlow renders incorrectly on macOS 10.15

[David Grieve]

Because the toy itself handles the highlighting, I believe this is a problem in 
the toy, not in the library.

Re: RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation

[David Grieve]

On Tue, 26 Nov 2019 09:22:01 GMT, Ajit Ghaisas  wrote:

> On Tue, 19 Nov 2019 14:29:16 GMT, David Grieve 
>  wrote:
> 
>> On Tue, 19 Nov 2019 10:48:52 GMT, Ajit Ghaisas  wrote:
>> 
>>> On Fri, 15 Nov 2019 09:14:04 GMT, Ajit Ghaisas  wrote:
>>> 
>>>> On Thu, 14 Nov 2019 18:33:05 GMT, Kevin Rushforth  wrote:
>>>> 
>>>>> On Tue, 12 Nov 2019 16:45:04 GMT, Ajit Ghaisas  
>>>>> wrote:
>>>>> 
>>>>>> **Issue :**
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8193445
>>>>>> 
>>>>>> **Background :**
>>>>>> The CSS performance improvement done in 
>>>>>> [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) had to 
>>>>>> be backed out due to functional regressions reported in 
>>>>>> [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), 
>>>>>> [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and 
>>>>>> [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951).
>>>>>> Refer to [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) 
>>>>>> for more details on this backout. 
>>>>>> 
>>>>>> **Description :**
>>>>>> This PR reintroduces the CSS performance improvement fix done in 
>>>>>> [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) while 
>>>>>> addressing the functional regressions that were reported in 
>>>>>> [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), 
>>>>>> [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and 
>>>>>> [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951).
>>>>>> For ease of review, I have made two separate commits -
>>>>>> 1) [Commit 
>>>>>> 1](https://github.com/openjdk/jfx/pull/34/commits/d964675ebc2a42f2fd6928b773819502683f2334)
>>>>>>  - Reintroduces the CSS performance improvement fix done in 
>>>>>> [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) - most 
>>>>>> of the patch applied cleanly.
>>>>>> 2) [Commit 2 
>>>>>> ](https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f)-
>>>>>>  fixes the functional regressions keeping performance improvement intact 
>>>>>> + adds a system test
>>>>>> 
>>>>>> **Root Cause :**
>>>>>> CSS performance improvement fix proposed in [JDK-8151756 
>>>>>> ](https://bugs.openjdk.java.net/browse/JDK-8151756)correctly avoids the 
>>>>>> redundant CSS reapplication to children of a Parent. 
>>>>>> What was missed earlier in [JDK-8151756 
>>>>>> ](https://bugs.openjdk.java.net/browse/JDK-8151756) fix : "CSS 
>>>>>> reapplication to the Parent itself”. 
>>>>>> This missing piece was the root cause of all functional regressions 
>>>>>> reported against 
>>>>>> [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756)
>>>>>> 
>>>>>> **Fix :**
>>>>>> Fixed the identified root cause. See commit 2.
>>>>>> 
>>>>>> **Testing :**
>>>>>> 1. All passing unit tests continue to pass
>>>>>> 2. New system test (based on 
>>>>>> [JDK-8209830](https://bugs.openjdk.java.net/browse/JDK-8209830)) added 
>>>>>> in this PR - fails before this fix and passes after the fix
>>>>>> 3. System test JDK8183100Test continues to pass
>>>>>> 4. All test cases attached to regressions 
>>>>>> [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), 
>>>>>> [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and 
>>>>>> [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951) pass 
>>>>>> with this fix
>>>>>> 
>>>>>> In addition, testing by community with specific CSS performance / 
>>>>>> functionality will be helpful.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Commits:
>>>>>>  - 12ea8220: Fix for functional regressions of JDK-8151756 + add a sytem 
>>>>>> test
>>>>>>  - d964675e: Reintroduce JDK-8151756 CSS performance 

Re: [Approved] RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation

[David Grieve]

On Tue, 12 Nov 2019 16:45:04 GMT, Ajit Ghaisas  wrote:

> **Issue :**
> https://bugs.openjdk.java.net/browse/JDK-8193445
> 
> **Background :**
> The CSS performance improvement done in 
> [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) had to be 
> backed out due to functional regressions reported in 
> [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), 
> [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and 
> [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951).
> Refer to [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) for 
> more details on this backout. 
> 
> **Description :**
> This PR reintroduces the CSS performance improvement fix done in 
> [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) while 
> addressing the functional regressions that were reported in 
> [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), 
> [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and 
> [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951).
> For ease of review, I have made two separate commits -
> 1) [Commit 
> 1](https://github.com/openjdk/jfx/pull/34/commits/d964675ebc2a42f2fd6928b773819502683f2334)
>  - Reintroduces the CSS performance improvement fix done in 
> [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) - most of the 
> patch applied cleanly.
> 2) [Commit 2 
> ](https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f)-
>  fixes the functional regressions keeping performance improvement intact + 
> adds a system test
> 
> **Root Cause :**
> CSS performance improvement fix proposed in [JDK-8151756 
> ](https://bugs.openjdk.java.net/browse/JDK-8151756)correctly avoids the 
> redundant CSS reapplication to children of a Parent. 
> What was missed earlier in [JDK-8151756 
> ](https://bugs.openjdk.java.net/browse/JDK-8151756) fix : "CSS reapplication 
> to the Parent itself”. 
> This missing piece was the root cause of all functional regressions reported 
> against [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756)
> 
> **Fix :**
> Fixed the identified root cause. See commit 2.
> 
> **Testing :**
> 1. All passing unit tests continue to pass
> 2. New system test (based on 
> [JDK-8209830](https://bugs.openjdk.java.net/browse/JDK-8209830)) added in 
> this PR - fails before this fix and passes after the fix
> 3. System test JDK8183100Test continues to pass
> 4. All test cases attached to regressions 
> [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), 
> [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and 
> [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951) pass with 
> this fix
> 
> In addition, testing by community with specific CSS performance / 
> functionality will be helpful.
> 
> 
> 
> Commits:
>  - 12ea8220: Fix for functional regressions of JDK-8151756 + add a sytem test
>  - d964675e: Reintroduce JDK-8151756 CSS performance fix
> 
> Changes: https://git.openjdk.java.net/jfx/pull/34/files
>  Webrev: https://webrevs.openjdk.java.net/jfx/34/webrev.00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8193445
>   Stats: 121 lines in 5 files changed: 104 ins; 0 del; 17 mod
>   Patch: https://git.openjdk.java.net/jfx/pull/34.diff
>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/34/head:pull/34

Approved by dgrieve (Reviewer).

PR: https://git.openjdk.java.net/jfx/pull/34

Re: RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation

[David Grieve]

On Tue, 19 Nov 2019 10:48:52 GMT, Ajit Ghaisas  wrote:

> On Fri, 15 Nov 2019 09:14:04 GMT, Ajit Ghaisas  wrote:
> 
>> On Thu, 14 Nov 2019 18:33:05 GMT, Kevin Rushforth  wrote:
>> 
>>> On Tue, 12 Nov 2019 16:45:04 GMT, Ajit Ghaisas  wrote:
>>> 
 **Issue :**
 https://bugs.openjdk.java.net/browse/JDK-8193445
 
 **Background :**
 The CSS performance improvement done in 
 [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) had to be 
 backed out due to functional regressions reported in 
 [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), 
 [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and 
 [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951).
 Refer to [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) 
 for more details on this backout. 
 
 **Description :**
 This PR reintroduces the CSS performance improvement fix done in 
 [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) while 
 addressing the functional regressions that were reported in 
 [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), 
 [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and 
 [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951).
 For ease of review, I have made two separate commits -
 1) [Commit 
 1](https://github.com/openjdk/jfx/pull/34/commits/d964675ebc2a42f2fd6928b773819502683f2334)
  - Reintroduces the CSS performance improvement fix done in 
 [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) - most of 
 the patch applied cleanly.
 2) [Commit 2 
 ](https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f)-
  fixes the functional regressions keeping performance improvement intact + 
 adds a system test
 
 **Root Cause :**
 CSS performance improvement fix proposed in [JDK-8151756 
 ](https://bugs.openjdk.java.net/browse/JDK-8151756)correctly avoids the 
 redundant CSS reapplication to children of a Parent. 
 What was missed earlier in [JDK-8151756 
 ](https://bugs.openjdk.java.net/browse/JDK-8151756) fix : "CSS 
 reapplication to the Parent itself”. 
 This missing piece was the root cause of all functional regressions 
 reported against 
 [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756)
 
 **Fix :**
 Fixed the identified root cause. See commit 2.
 
 **Testing :**
 1. All passing unit tests continue to pass
 2. New system test (based on 
 [JDK-8209830](https://bugs.openjdk.java.net/browse/JDK-8209830)) added in 
 this PR - fails before this fix and passes after the fix
 3. System test JDK8183100Test continues to pass
 4. All test cases attached to regressions 
 [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), 
 [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and 
 [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951) pass with 
 this fix
 
 In addition, testing by community with specific CSS performance / 
 functionality will be helpful.
 
 
 
 Commits:
  - 12ea8220: Fix for functional regressions of JDK-8151756 + add a sytem 
 test
  - d964675e: Reintroduce JDK-8151756 CSS performance fix
 
 Changes: https://git.openjdk.java.net/jfx/pull/34/files
  Webrev: https://webrevs.openjdk.java.net/jfx/34/webrev.00
   Issue: https://bugs.openjdk.java.net/browse/JDK-8193445
   Stats: 121 lines in 5 files changed: 104 ins; 0 del; 17 mod
   Patch: https://git.openjdk.java.net/jfx/pull/34.diff
   Fetch: git fetch https://git.openjdk.java.net/jfx pull/34/head:pull/34
>>> 
>>> While we are still discussing the fix itself, I added a few comments on the 
>>> new test. It generally looks good, but should be run on a variety of 
>>> systems, with and without the fix (once we have a final fix that we are 
>>> satisfied with).
>>> 
>>> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java
>>>  line 26:
>>> 
 25: 
 26: package test.robot.javafx.scene;
 27: 
>>> 
>>> There is no need for this test to require robot. I recommend moving it to 
>>> `test.javafx.scene` (and not inherit from `VisualTestBase`).
>>> 
>>> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java
>>>  line 55:
>>> 
 54: 
 55: public class CSSPerf_JDK8193445Test extends VisualTestBase {
 56: 
>>> 
>>> We have moved away from putting the bug ID in the test class name, so I 
>>> recommend renaming it.
>>> 
>>> tests/system/src/test/java/test/robot/javafx/scene/CSSPerf_JDK8193445Test.java
>>>  line 78:
>>> 
 77: HBox hbox = new HBox();
 78: for (int i = 0; i < 300; i++) {
 79: hbox = new HBox(new Text("y"), hbox);
>>> 
>>> In my testing on 

Re: RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation

[David Grieve]

On Thu, 14 Nov 2019 15:02:40 GMT, Dean Wookey  wrote:

> On Thu, 14 Nov 2019 14:27:24 GMT, Kevin Rushforth  wrote:
> 
>> On Thu, 14 Nov 2019 12:34:56 GMT, Kevin Rushforth  wrote:
>> 
>>> On Thu, 14 Nov 2019 11:33:24 GMT, Dean Wookey  wrote:
>>> 
>>>> On Wed, 13 Nov 2019 19:10:45 GMT, David Grieve 
>>>>  wrote:
>>>> 
>>>>> On Tue, 12 Nov 2019 16:55:45 GMT, Ajit Ghaisas  
>>>>> wrote:
>>>>> 
>>>>>> On Tue, 12 Nov 2019 16:52:54 GMT, Ajit Ghaisas  
>>>>>> wrote:
>>>>>> 
>>>>>>> On Tue, 12 Nov 2019 16:45:04 GMT, Ajit Ghaisas  
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> **Issue :**
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8193445
>>>>>>>> 
>>>>>>>> **Background :**
>>>>>>>> The CSS performance improvement done in 
>>>>>>>> [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) had to 
>>>>>>>> be backed out due to functional regressions reported in 
>>>>>>>> [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), 
>>>>>>>> [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and 
>>>>>>>> [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951).
>>>>>>>> Refer to 
>>>>>>>> [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) for 
>>>>>>>> more details on this backout. 
>>>>>>>> 
>>>>>>>> **Description :**
>>>>>>>> This PR reintroduces the CSS performance improvement fix done in 
>>>>>>>> [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) while 
>>>>>>>> addressing the functional regressions that were reported in 
>>>>>>>> [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), 
>>>>>>>> [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and 
>>>>>>>> [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951).
>>>>>>>> For ease of review, I have made two separate commits -
>>>>>>>> 1) [Commit 
>>>>>>>> 1](https://github.com/openjdk/jfx/pull/34/commits/d964675ebc2a42f2fd6928b773819502683f2334)
>>>>>>>>  - Reintroduces the CSS performance improvement fix done in 
>>>>>>>> [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) - most 
>>>>>>>> of the patch applied cleanly.
>>>>>>>> 2) [Commit 2 
>>>>>>>> ](https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f)-
>>>>>>>>  fixes the functional regressions keeping performance improvement 
>>>>>>>> intact + adds a system test
>>>>>>>> 
>>>>>>>> **Root Cause :**
>>>>>>>> CSS performance improvement fix proposed in [JDK-8151756 
>>>>>>>> ](https://bugs.openjdk.java.net/browse/JDK-8151756)correctly avoids 
>>>>>>>> the redundant CSS reapplication to children of a Parent. 
>>>>>>>> What was missed earlier in [JDK-8151756 
>>>>>>>> ](https://bugs.openjdk.java.net/browse/JDK-8151756) fix : "CSS 
>>>>>>>> reapplication to the Parent itself”. 
>>>>>>>> This missing piece was the root cause of all functional regressions 
>>>>>>>> reported against 
>>>>>>>> [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756)
>>>>>>>> 
>>>>>>>> **Fix :**
>>>>>>>> Fixed the identified root cause. See commit 2.
>>>>>>>> 
>>>>>>>> **Testing :**
>>>>>>>> 1. All passing unit tests continue to pass
>>>>>>>> 2. New system test (based on 
>>>>>>>> [JDK-8209830](https://bugs.openjdk.java.net/browse/JDK-8209830)) added 
>>>>>>>> in this PR - fails before this fix and passes after the fix
>>>>>>>> 3. System test JDK8183100Test continues to pass
>>>>>>>> 4. All test cases attached to regressions 
>>>>>>>> [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-81

Re: RFR: 8193445: JavaFX CSS is applied redundantly leading to significant performance degradation

[David Grieve]

On Tue, 12 Nov 2019 16:55:45 GMT, Ajit Ghaisas  wrote:

> On Tue, 12 Nov 2019 16:52:54 GMT, Ajit Ghaisas  wrote:
> 
>> On Tue, 12 Nov 2019 16:45:04 GMT, Ajit Ghaisas  wrote:
>> 
>>> **Issue :**
>>> https://bugs.openjdk.java.net/browse/JDK-8193445
>>> 
>>> **Background :**
>>> The CSS performance improvement done in 
>>> [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) had to be 
>>> backed out due to functional regressions reported in 
>>> [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), 
>>> [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and 
>>> [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951).
>>> Refer to [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) 
>>> for more details on this backout. 
>>> 
>>> **Description :**
>>> This PR reintroduces the CSS performance improvement fix done in 
>>> [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) while 
>>> addressing the functional regressions that were reported in 
>>> [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), 
>>> [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and 
>>> [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951).
>>> For ease of review, I have made two separate commits -
>>> 1) [Commit 
>>> 1](https://github.com/openjdk/jfx/pull/34/commits/d964675ebc2a42f2fd6928b773819502683f2334)
>>>  - Reintroduces the CSS performance improvement fix done in 
>>> [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756) - most of 
>>> the patch applied cleanly.
>>> 2) [Commit 2 
>>> ](https://github.com/openjdk/jfx/pull/34/commits/12ea8220a730ff8d98d520ce870691d54f0de00f)-
>>>  fixes the functional regressions keeping performance improvement intact + 
>>> adds a system test
>>> 
>>> **Root Cause :**
>>> CSS performance improvement fix proposed in [JDK-8151756 
>>> ](https://bugs.openjdk.java.net/browse/JDK-8151756)correctly avoids the 
>>> redundant CSS reapplication to children of a Parent. 
>>> What was missed earlier in [JDK-8151756 
>>> ](https://bugs.openjdk.java.net/browse/JDK-8151756) fix : "CSS 
>>> reapplication to the Parent itself”. 
>>> This missing piece was the root cause of all functional regressions 
>>> reported against 
>>> [JDK-8151756](https://bugs.openjdk.java.net/browse/JDK-8151756)
>>> 
>>> **Fix :**
>>> Fixed the identified root cause. See commit 2.
>>> 
>>> **Testing :**
>>> 1. All passing unit tests continue to pass
>>> 2. New system test (based on 
>>> [JDK-8209830](https://bugs.openjdk.java.net/browse/JDK-8209830)) added in 
>>> this PR - fails before this fix and passes after the fix
>>> 3. System test JDK8183100Test continues to pass
>>> 4. All test cases attached to regressions 
>>> [JDK-8185709](https://bugs.openjdk.java.net/browse/JDK-8185709), 
>>> [JDK-8183100](https://bugs.openjdk.java.net/browse/JDK-8183100) and 
>>> [JDK-8168951](https://bugs.openjdk.java.net/browse/JDK-8168951) pass with 
>>> this fix
>>> 
>>> In addition, testing by community with specific CSS performance / 
>>> functionality will be helpful.
>>> 
>>> 
>>> 
>>> Commits:
>>>  - 12ea8220: Fix for functional regressions of JDK-8151756 + add a sytem 
>>> test
>>>  - d964675e: Reintroduce JDK-8151756 CSS performance fix
>>> 
>>> Changes: https://git.openjdk.java.net/jfx/pull/34/files
>>>  Webrev: https://webrevs.openjdk.java.net/jfx/34/webrev.00
>>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8193445
>>>   Stats: 121 lines in 5 files changed: 104 ins; 0 del; 17 mod
>>>   Patch: https://git.openjdk.java.net/jfx/pull/34.diff
>>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/34/head:pull/34
>> 
>> Reviewers: @kevinrushforth and @arapte
> 
> It will be helpful if I can get some feedback from community with additional 
> testing apart from what is mentioned in the description.

Has this been checked with SubScene? Two cases would be 1) SubScene inheriting 
a style from its parent, and 2) behavior of a parent in the SubScene itself. I 
don't expect that this would be an issue, but there is some special handling of 
CSS in SubScene IIRC.

PR: https://git.openjdk.java.net/jfx/pull/34

RE: Custom Fonts in User Agent Stylesheets

[David Grieve]

This seems like a bug. Certainly overriding Region#getUserAgentStylesheet() is 
the preferred way of customizing styles for a control.  Maybe the styles from 
the Region UA stylesheet aren’t being considered when doing a font lookup. That 
would for sure be a bug.

But there are a lot of moving parts.

Are there other stylesheets that might take precedence? Are there other styles 
in the custom stylesheet that are/are not working? Do you have a short example 
that reproduces the issue?

Sent from Mail for Windows 10


From: openjfx-dev  on behalf of Dirk 
Lemmermann 
Sent: Friday, October 4, 2019 5:59:17 AM
To: openjfx-dev@openjdk.java.net Mailing 
Subject: Custom Fonts in User Agent Stylesheets

I noticed today that the custom fonts I defined in a user agent stylesheet of a 
custom control are not being used. It only started working when I “manually” 
added the stylesheet to the control via getStylesheets().add() instead of 
overriding getUserAgentStylesheet().

Does anyone know if this is intentional or a bug? Are there certain things that 
JavaFX does not support depending on the “type” of stylesheet?

Dirk

Re: Custom InputControl w/o char->string conversion

[David Grieve]

Have you looked at javax.security.auth.Destroyable?

On 3/26/19 9:07 AM, Finn Herpich wrote:

Hi Nicolas,

thanks for the long write up. I'm indeed working with a lot of C# in 
the last year, but that is a pure accident, to reproduce the 
SecureString-class was not my intention.
I'm totally aware of the problems you are listing, but sadly I've to 
handle sensitive information which force me to reduce the attack 
surface to a bare minimum for certain values. If an attacker has full 
access to my process, as you said, it is game over; However I'm trying 
to reduce the points in time where a value could get leaked to a 
pagefile or whatever you can think of to be recovered later by memory 
forensics and such. I know that I'm limit to how the OS handles 
memory, memory access rights within the system, etc. and I've talked 
to multiple penetration testers/security analysts in the past few weeks.


So coming from that requirement I did some tests with char arrays in 
java which I at least could overwrite quickly enough to minimize the 
points in time where it could be read and wasn't able to find any 
traces left in memory (as you also mentioned with the .fill method). 
However using OpenJFX controls I found my inputs multiple times in 
memory afterwards, which lead me to the 
com.sun.javafx.tk.quantum.GlassViewEventHandler class where the input 
event is converted into a string and I somehow have the impression 
that it would be some major work to get this out of the event flow for 
a specialized control.


In the worst case I've to go back to C++, where it is hard to write 
secure code, or Rust/Go which don't have such a wonderful and easy 
deployable cross platform GUI like Java does with openjfx.


Cheers,
Finn

On 26.03.19 12:49, Nicolas Therrien wrote:

Hi Finn,

I assume you are coming from a C# background and looking for a 
SecureString equivalent in Java.   Check out this:
https://github.com/OWASP/passfault/blob/master/core/src/main/java/org/owasp/passfault/impl/SecureString.java 



You could write your own javafx component with OWASP SecureString and 
achieve the same result as in C#.


Hopefully this answers your question.

That being said, what you said about being faster than garbage 
collection and again assuming you had SecureString in mind, makes me 
think you might not really understand the purpose of SecureString in 
C#.  It does NOT guarantee that an attacker would not be able to see 
the string if they had access to the application's runtime memory. 
Think about it: if you can TYPE your password, there was a byte array 
containing your clear text password before it was put in the 
SecureString. And then if you can USE that password (during a 
database connection), there was a byte array containing your clear 
text password when you sent it to the driver. A simple breakpoint in 
the right spot and a heap dump would reveal your password, always. 
The reason is simple: your application does need to know the password!


The purpose of SecureString is not to protect from being able to 
capture the password in memory or from heap dumps. The purpose is to 
avoid the password from leaking in log files, console output or in 
application messaging. By creating a separate String class extension 
for it, the developers made sure that inadvertently calling 
"toString()" (as a logger would do) would return some encrypted garbage.


SecureString is a simply a Safeguard against leaking sensitive 
strings in logs, console output and application messaging.


If you are still concerned about someone inspecting the heap and look 
for the short lived byte arrays containing what you typed, you can 
always call .fill(0) on that byte array when you're done with it to 
make it harder for the attacker. The OWASP class i shared with you 
does that in the constructor. But again, if the attacker has access 
to your process, all he has to do is set a breakpoint to the 
SecureString constructor and voila, he can read the byte buffer 
before its encrypted.  Wiping only makes sure that the original byte 
array could not inadvertently be the source of a leak later (ie 
someone uses the byte array instead of the string)..That's the real 
reason why the OWASP class is wiping the array.


Best regards,

*Nicolas Therrien*

Senior Software Developer

/https://www.motorolasolutions.com/content/dam/msi/images/logos/corporate/msiemailsignature.png/ 



*o*: +1.819.931.2053



On Tue, Mar 26, 2019 at 4:42 AM Finn Herpich > wrote:


    Hi everyone,

    I'll hope this is the right place to ask. I'm currently evaluating
    multiple ways to write a cross platform application with the
    requirement
    to be able to clear certain inputs from memory rather quickly and 
not

    wait for the GCs mercy.

    I've tracked the JavaFx TextInputControls back to the point where 
the

    character from the input event is transformed into a string. Which
    happens roughly in 

Re: EM Font Size Performance

[David Grieve]

I think the change looks reasonable. Has it been tested against things 
like changing -fx-font in some parent, or setting the font property in 
some parent? What about popups? If I have a tooltip on a Label, for 
example, does the tooltip properly pick up font from the Label's style 
or font property?


On 1/17/19 11:10 AM, Dean Wookey wrote:
This is almost a year old, but I think I've found a partial solution 
(David's suggestions on a top down approach still make sense, but 
that's a bigger issue). Caching an uncached call to lookupFont 
definitely improves performance.


https://github.com/DeanWookey/openjdk-jfx/commit/e12f00fb6c2fc690c0a7fb089f7b0c81d6930fa9 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_DeanWookey_openjdk-2Djfx_commit_e12f00fb6c2fc690c0a7fb089f7b0c81d6930fa9=DwMFaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=H6jKHjHoLf6vCNF0PYEnJ6cS6kScbGLraJqgoRs9znU=xH8dfYiQe6JO5VXucoVgtnsubTZNAhr0XVK5OaSDDbs=YvsZxESGrm40L34aR16E2fQCKjh8tCQ311R3h63hu0c=>


Using a stack of 50 stackpanes instead of 20, I now get the following:

Before modification:

With setting font size: 10675ms
Without setting font size: 49243ms

After modification:

With setting font size: 10852ms
Without setting font size: 20357ms

Dean

On Thu, Apr 19, 2018 at 9:51 PM David Grieve <mailto:david.gri...@oracle.com>> wrote:


I was thinking about
https://bugs.openjdk.java.net/browse/JDK-8177635 and
https://bugs.openjdk.java.net/browse/JDK-8090462

There is also https://bugs.openjdk.java.net/browse/JDK-8187955


On 4/19/18 3:02 PM, Nir Lisker wrote:

I think this is the issue:
https://bugs.openjdk.java.net/browse/JDK-8088615. There's also
https://bugs.openjdk.java.net/browse/JDK-8193445.

- Nir

On Thu, Apr 19, 2018 at 1:42 PM, David Grieve
mailto:david.gri...@oracle.com>> wrote:

Resolving the relative size involves a lot of lookup. You
have to go up the scene-graph from the child to find a font
style. If you get to the root and haven't found a font style,
then use the default font. Performance in this area could be
vastly improved by passing the size from either a font style
or the default font down the scene-graph as styles are
evaluated. There are other style lookups that could benefit
from this as well, resolving looked-up colors for example. I
believe I created a bug for this a long time ago.



On 4/19/18 5:57 AM, Dean Wookey wrote:

Hi All,

In our application we add and remove a lot of nodes to
the scene graph
regularly, and also make use of em font sizes to scale
certain parts of our
application. We've noticed performance issues when adding
nodes to the
scene, and it seems to be related to em sizes in our css.

As a test we added a chain of 20 stackpanes to a root
stackpane. On the
root, we set a font size of 8pt via inline css. We then
added and removed a
new tableview from the deepest stackpane 500 times,
waiting for the node to
render after each add and remove.

In each of the experiments, we compared adding tableviews
without css and
adding tableviews with an inline css font size of 8pt. We
then tried
setting different font sizes in the stackpane chain.

I've attached sample code for these experiments.

The results (on jdk 9.0.4 - jdk 10 was similar) are as
follows:

Setting a 1em font size on all stackpanes except the root.
With font on tableview: 14707ms
Without font on tableview: 27725ms

Setting a 1em font size on the first child of the root only.
With font on tableview: 14221ms
Without font on tableview: 19187ms

Using the original setup with no additional fonts.
With font on tableview: 13990ms
Without font on tableview: 13847ms

It looks like using a relative font size has a large
effect performance
wise on descendant nodes. I would expect some amount of
font size caching
in the chain of stackpanes since I'm reusing the same
chain and
adding/removing nodes from that chain repeatedly.

I'm not sure how valid my test is, or how much of an
issue this really is
in practice?

Dean

Re: JDK-8193445 Performance Test

[David Grieve]

One of the dangers of mucking around with the CSS code is whether or not 
the changes break things like popups, dialogs, menus. And whether or not 
the change breaks inline styles versus attributes set in code, versus 
stylesheets added to the scene/subscene/control, versus default 
stylesheets. And whether or not the changes breaks skins for controls.


Reapplying CSS to a Node but not its children could cause a problem if 
there are styles in the parent or the parent's parents that affect the 
children. It seems like bypassing children in reapplyCSS is bound to 
cause a regression.


Also, because a new scene root could affect styles, CSS is reapplied 
after calling sceneChanged - your change puts it before, so I question 
whether or not this will cause a regression. I think if you skip 
reapplying CSS when a Node's scene has changed, then the children won't 
get the correct styles, and this will affect layout.


I haven't spent much time evaluating this change in detail, but I'm 
doubtful that it won't cause regressions.



On 11/7/18 2:57 AM, Dean Wookey wrote:

Hi,

I was going to ask if it was possible to reopen JDK-8151756 (
https://bugs.openjdk.java.net/browse/JDK-8151756) since it was fixed but
reverted in JDK-8183100 (https://bugs.openjdk.java.net/browse/JDK-8183100)
after causing several regressions. I only noticed now that a followup bug
was created: JDK-8193445 which reopens the issue.

The code below demonstrates the problem where adding nodes to the scene
graph all at once performs exponentially slower than adding them one by
one. I get the following results with jfx11.0.1:

One by one: 138ms
All at once: 16704ms

I've made a potential fix, different to the one tried previously which
applies the css as if the nodes were being added one by one:
https://github.com/DeanWookey/openjdk-jfx/commit/65a1ed82bce262294f1969e9a12e1126ec8a1ec6

It passes the main tests, as well as the systemTest JDK8183100Test.java
from https://bugs.openjdk.java.net/browse/JDK-8193494.

This is probably not a suitable issue to work on for a first time
contributor, but perhaps I could work on a performance test if someone can
point me in the direction of existing performance tests?

Dean

package applycsstest;

import javafx.application.Application;
import javafx.application.Platform;
import javafx.scene.Scene;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;

/**
  *
  * @author Dean
  */
public class ApplyCssTest extends Application {

 @Override
 public void start(Stage primaryStage) {
 System.out.println("One by one: " + addToSceneOneByOne() + "ms");
 System.out.println("All at once: " + addToSceneAllAtOnce() + "ms");
 Platform.exit();
 }

 public static void main(String[] args) {
 launch(args);
 }

 public long addToSceneOneByOne() {
 StackPane root = new StackPane();
 Scene scene = new Scene(root, 300, 250);

 long start = System.currentTimeMillis();
 StackPane firstChild = new StackPane();
 root.getChildren().add(firstChild); //add to the scene graph first
 addNodesOneByOne(1000, firstChild); //then add children one by one
 return System.currentTimeMillis() - start;
 }

 public long addToSceneAllAtOnce() {
 StackPane root = new StackPane();
 Scene scene = new Scene(root, 300, 250);

 long start = System.currentTimeMillis();
 StackPane firstChild = new StackPane();
 addNodesOneByOne(1000, firstChild); //build the node up, then
 root.getChildren().add(firstChild); //add to scene graph all at once
 return System.currentTimeMillis() - start;
 }

 public void addNodesOneByOne(int numToAdd, StackPane parent) {
 StackPane last = parent;
 for (int i = 0; i < numToAdd; i++) {
 StackPane curr = new StackPane();
 last.getChildren().add(curr);
 last = curr;
 }
 }
}

Re: Maybe a TitledPane bug

[David Grieve]

On 11/1/18 2:19 PM, Sverre Moe wrote:


scene.getStylesheets().add(getClass().getResource("light.css").toExternalForm());


Here is the CSS content for light.css
.titled-pane > .title {
    -fx-color: rgb(220, 220, 220);

Well, there you go. Your 'light.css' style trumps the setBackground. The 
reason for this is that this allows an application to be deployed with 
explicitly set, styleable properties - e.g. titleNode.setBackground(...) 
- but still allow that application to be styled from a stylesheet.


From the JavaFX CSS reference:

The implementation allows designers to style an application by using style
sheets to override property values set from code. This has implications for
the cascade; particularly, when does a style from a style sheet override a
value set from code? The JavaFX CSS implementation applies the following
order of precedence; a style from a user agent style sheet has lower
priority than a value set from code, which has lower priority than a Scene
or Parent style sheet. Inline styles have highest precedence. Style sheets
from a Parent instance are considered to be more specific than those styles
from Scene style sheets.
 

Re: Maybe a TitledPane bug

[David Grieve]

It's hard to tell without some short, self-contained, correct example. 
This sample I crafted here doesn't reproduce the issue.


@Override public void start(Stage primaryStage) {

final TitledPane titledPane =new TitledPane("Button Pane",new 
Button("Button"));
final HBox root =new HBox();
root.getChildren().add(titledPane);

primaryStage.setTitle("Maybe a TitledPane bug");
primaryStage.setScene(new Scene(root,300,250));
primaryStage.show();

final Region titleNode = (Region)titledPane.lookup("*.title");
titleNode.setBackground(new Background(new 
BackgroundFill(Color.GREEN,null,null)));
}



On 10/31/18 6:58 PM, Sverre Moe wrote:

I am not sure if I have stumbled upon a bug in JavaFX, or perhaps it is
simply something I am doing wrong.

After setting the TitledPane title background programmatically, then when
hovering the background color is reset to the previous value from CSS.
I get same behavior in both JavaFX 8 and JavaFX 11.

Color color = Color.valueOf("#00ff11");
titleNode.setBackground(new Background(new BackgroundFill(color, null,
null)));

titleNode.setStyle("-fx-background-color:#00ff11;");

Setting the style property seems to work, but why doesn't the
programmatically approach work?

https://stackoverflow.com/questions/53083005/javafx-titledpane-changed-title-background-is-reset-on-mouse-entered/

/Sverre

Re: JavaFX in-memory dynamic CSS file editing and applying

[David Grieve]

Just setStyle -fx-theme-header (etc.) on the root node.


On 10/15/18 1:05 AM, Ty Young wrote:
Does JavaFX have an API for dynamically editing and applying CSS files 
in-memory? If not, would there be any possibility in one ever being made?



My reasoning for such an API is, instead of switching between 
completely separate CSS files and having to update each whenever I 
need to support a new component, I'd like the ability to just have 1 
CSS file and edit it's values in-memory and have it reflected in 
JavaFX as soon as the change is made. For example instead of changing 
the individual components themselves I'd like to get all of this:



*
{
    -fx-theme-header: #44;
    -fx-theme-background: #3D3D3D;
    -fx-theme-background-alt: #2E2E2E;
    -fx-theme-selected: #F0544C;
    -fx-theme-label-text: #D2D2D2;
    -fx-theme-selectable-hover: #454545;
    -fx-theme-tab-close-color: -fx-theme-label-text;

    -fx-highlight-fill: -fx-theme-selected;
}


and modify it via a JavaFX API to change it to something like:


*
{
    -fx-theme-header: #FF;
    -fx-theme-background: -fx-theme-header;
    -fx-theme-background-alt: #F2F2F2;
    -fx-theme-selected: #CBEAFF;
    -fx-theme-label-text: #33;
    -fx-theme-selectable-hover: #E1E1E1;
    -fx-theme-tab-close-color: -fx-theme-label-text;

    -fx-highlight-fill: -fx-theme-selected;
}


Since these are used throughout the CSS file, all the components that 
use these will be updated.

Re: JavaFX 11 on Android

[David Grieve]

You just need Android Studio 3 for try-with-resources. See 
https://developer.android.com/studio/write/java8-support


I've never had a problem using java.util.logging with Android. Logging 
ends up in logcat.


On 10/4/18 2:45 PM, Nir Lisker wrote:

But indeed, there are other things (e.g. try-resource with variable) that
can not be used on Android. In general, there are too much restrictions,
which is why we need a bundled Java 11 in the longer term.




How does JavaFXPorts deal with this?

We use java.util.logging for now.


That will require reverting the work of removing it [1] :) So yes, a fork
seems adequate for now and in the future we can re-evaluate the need for
j.u.l. (related: [2]).

[1] https://bugs.openjdk.java.net/browse/JDK-8195974
[2] https://bugs.openjdk.java.net/browse/JDK-8209036

On Thu, Oct 4, 2018 at 9:13 PM Johan Vos  wrote:



On Thu, Oct 4, 2018 at 8:01 PM Nir Lisker  wrote:


Hi Johan,

Thanks for the work. A couple of questions:



I worked from the openjfx/develop repository and created a version that
works on Android (will work on iOS soon).


I'm not very familiar with the state of mobile. Doesn't Android support
only up to Java 8 API? What happens if there is 'var' in the codebase, for
example?


"var" will be ok as I think that has no influence at runtime?
But indeed, there are other things (e.g. try-resource with variable) that
can not be used on Android. In general, there are too much restrictions,
which is why we need a bundled Java 11 in the longer term.



4. Changes in common java classes (e.g. no System.Logger). Those are a

problem.


If System.Logger is not available on Android an iOS, what is available
instead? jul or a native logger?


We use java.util.logging for now.



- Nir

On Thu, Oct 4, 2018 at 8:01 PM Johan Vos  wrote:


Hi,

I worked from the openjfx/develop repository and created a version that
works on Android (will work on iOS soon).
This required some changes, as we're running on top of the Android VM,
which is not really Java (not even close).
The longer-term goal is to run a JVM on Android as well, but that is not
something to discuss in this topic.

The changes I had to make are in this diff:

https://github.com/javafxports/openjdk-jfx/compare/develop...johanvos:android

There are a number of changes:

1. Changes in the Android specific files (e.g. FXDalvikEntity): those are
mainly changes we did in the 8-tree, but that were never sent upstream. I
think most of those can be upstreamed (after cleanup and review of
course)

2. Changes in Monocle, mainly related to scale factor and HiDPI. Those
can
probably be upstreamed as well

3. Changes in the buildSrc/dalvik.gradle. Those are android-only, so can
be
upstreamed too.

4. Changes in common java classes (e.g. no System.Logger). Those are a
problem.

While I am in favour of leveraging the latest version of Java for doing
JavaFX development, I do realise this breaks the Android port (not the
iOS
port, as we use a VM based on OpenJDK already there).
While in theory we could deal with this using reflection (and this has
been
done in the 8-tree, e.g. for isIdeographic()), I don't think this is a
good
idea.

My proposal would therefore be that I split the changes into
Android/Dalvik/Monocle changes that do not affect any other platform, and
create PR's for merging these changes in upstream. While my prototype is
working (see https://twitter.com/johanvos/status/1047804607320260608)  I
need to clean up the patches, and I suggest I create smaller PR's that
are
easier to digest.

For the changes in the common classes, I think it's best to use a fork,
or
to patch the system at build time -- rather than polluting the main
repository with reflection-based checks.

Thoughts?

- Johan

Re: Formatting and Validating

[David Grieve]

You can set a javafx.scene.control.TextFormatter on any TextInputControl


On 8/24/18 4:58 PM, Miroslav Nachev wrote:

Hi,

Is there any intention of adding formatting and validating of data in
JavaFX? Are there any active projects or libraries for that?

For example integer, decimal, currency, custom, etc.? Local data
representation, which is typical for each country.

It will be good if Formatting and Validating is in real-time during typing.


Regards,
Miro.

Re: EM Font Size Performance

[David Grieve]

I was thinking about https://bugs.openjdk.java.net/browse/JDK-8177635 
and https://bugs.openjdk.java.net/browse/JDK-8090462


There is also https://bugs.openjdk.java.net/browse/JDK-8187955


On 4/19/18 3:02 PM, Nir Lisker wrote:
I think this is the issue: 
https://bugs.openjdk.java.net/browse/JDK-8088615. There's also 
https://bugs.openjdk.java.net/browse/JDK-8193445.


- Nir

On Thu, Apr 19, 2018 at 1:42 PM, David Grieve <david.gri...@oracle.com 
<mailto:david.gri...@oracle.com>> wrote:


Resolving the relative size involves a lot of lookup. You have to
go up the scene-graph from the child to find a font style. If you
get to the root and haven't found a font style, then use the
default font. Performance in this area could be vastly improved by
passing the size from either a font style or the default font down
the scene-graph as styles are evaluated. There are other style
lookups that could benefit from this as well, resolving looked-up
colors for example. I believe I created a bug for this a long time
ago.



On 4/19/18 5:57 AM, Dean Wookey wrote:

Hi All,

In our application we add and remove a lot of nodes to the
scene graph
regularly, and also make use of em font sizes to scale certain
parts of our
application. We've noticed performance issues when adding
nodes to the
scene, and it seems to be related to em sizes in our css.

As a test we added a chain of 20 stackpanes to a root
stackpane. On the
root, we set a font size of 8pt via inline css. We then added
and removed a
new tableview from the deepest stackpane 500 times, waiting
for the node to
render after each add and remove.

In each of the experiments, we compared adding tableviews
without css and
adding tableviews with an inline css font size of 8pt. We then
tried
setting different font sizes in the stackpane chain.

I've attached sample code for these experiments.

The results (on jdk 9.0.4 - jdk 10 was similar) are as follows:

Setting a 1em font size on all stackpanes except the root.
With font on tableview: 14707ms
Without font on tableview: 27725ms

Setting a 1em font size on the first child of the root only.
With font on tableview: 14221ms
Without font on tableview: 19187ms

Using the original setup with no additional fonts.
With font on tableview: 13990ms
Without font on tableview: 13847ms

It looks like using a relative font size has a large effect
performance
wise on descendant nodes. I would expect some amount of font
size caching
in the chain of stackpanes since I'm reusing the same chain and
adding/removing nodes from that chain repeatedly.

I'm not sure how valid my test is, or how much of an issue
this really is
in practice?

Dean

Re: EM Font Size Performance

[David Grieve]

Resolving the relative size involves a lot of lookup. You have to go up 
the scene-graph from the child to find a font style. If you get to the 
root and haven't found a font style, then use the default font. 
Performance in this area could be vastly improved by passing the size 
from either a font style or the default font down the scene-graph as 
styles are evaluated. There are other style lookups that could benefit 
from this as well, resolving looked-up colors for example. I believe I 
created a bug for this a long time ago.



On 4/19/18 5:57 AM, Dean Wookey wrote:

Hi All,

In our application we add and remove a lot of nodes to the scene graph
regularly, and also make use of em font sizes to scale certain parts of our
application. We've noticed performance issues when adding nodes to the
scene, and it seems to be related to em sizes in our css.

As a test we added a chain of 20 stackpanes to a root stackpane. On the
root, we set a font size of 8pt via inline css. We then added and removed a
new tableview from the deepest stackpane 500 times, waiting for the node to
render after each add and remove.

In each of the experiments, we compared adding tableviews without css and
adding tableviews with an inline css font size of 8pt. We then tried
setting different font sizes in the stackpane chain.

I've attached sample code for these experiments.

The results (on jdk 9.0.4 - jdk 10 was similar) are as follows:

Setting a 1em font size on all stackpanes except the root.
With font on tableview: 14707ms
Without font on tableview: 27725ms

Setting a 1em font size on the first child of the root only.
With font on tableview: 14221ms
Without font on tableview: 19187ms

Using the original setup with no additional fonts.
With font on tableview: 13990ms
Without font on tableview: 13847ms

It looks like using a relative font size has a large effect performance
wise on descendant nodes. I would expect some amount of font size caching
in the chain of stackpanes since I'm reusing the same chain and
adding/removing nodes from that chain repeatedly.

I'm not sure how valid my test is, or how much of an issue this really is
in practice?

Dean

Re: CSSParser Color.parse() for unexpected CSS properties

[David Grieve]

On 4/4/18 10:44 AM, Matthew Elliot wrote:

Hi David, thanks for the quick response, the parser does seem to have 
knowledge of the property and values as in the method ...

ParsedValueImpl valueFor(String property, Term root, CSSLexer lexer)throws 
ParseException {}
it looks for particular properties for parsing... e.g.
} else if ("-fx-background-color".equals(prop)) {
 return parsePaintLayers(root);
}else if ("-fx-background-image".equals(prop)) {
 return parseURILayers(root);
}else if ("-fx-background-insets".equals(prop)) {
  return parseInsetsLayers(root);
... but fx-alignment and fx-shape for example aren't listed here and 
fall into this strange catch all place I noted in my previous email.


My follow up questions would be:

1. Why does it hit this for standard css properties as defined for 
JavaFX components(fx-alignment, fx-shape, etc) I.e. 
https://docs.oracle.com/javafx/2/api/javafx/scene/doc-files/cssref.html 
(hbox, vbox have -fx-alignment)
2. Even if it is wanted to be extensible, isn't by default attempting 
to parse a color where the property is not known and therefore 
triggering exception throw / catch on the thread critical to UI perf a 
less than optimal solution? Could it be changed to handle this more 
gracefully than catch / ignore exceptions?


Is it worth raising a ticket for such a topic, would it ever be 
considered for improvement.

I think it is worth raising a ticket.


Thanks again,
Matt


On 4 April 2018 at 16:20, David Grieve <david.gri...@oracle.com 
<mailto:david.gri...@oracle.com>> wrote:


The parser doesn't have any concept of what the property is or
value it might have. This allows the addition of new properties
(such as an user might add for their own CSS styles) without
having to modify the parser to handle them.



On 4/4/18 10:03 AM, Matthew Elliot wrote:

Hi all, (first post).

I was profiling our PROD JavaFX application recently I
discovered something
rather peculiar in the CSSParser. (jdk1.8.0_151)

I noticed several hundred IllegalArgumentExceptions on the
JavaApplicationThread where for various unrelated css
properties the
CSSParser is trying to parse a color. While the exception is
subsequently
caught and swallowed silently doing this hundred of times on
this thread is
rather ugly and caused *minor* delays in the application thread.

This happened for alignment, shape, and a few other properties
where
no-lookup case was found and it ended on approx. line 900 of
the CSSParser
in

colorValueOfString()

with a value like 'center'; clearly no color.

// if the property value is another property, then it needs to
be looked up.
boolean needsLookup = isIdent && properties.containsKey(text);
if (needsLookup || ((value = colorValueOfString(str)) == null )) {
     // If the value is a lookup, make sure to use the
lower-case text
so it matches the property
     // in the Declaration. If the value is not a lookup, then
use str
since the value might
     // be a string which could have some case sensitive meaning
     //
     // TODO: isIdent is needed here because of RT-38345. This
effectively undoes RT-38201
     value = new ParsedValueImpl<String,String>(needsLookup ?
text :
str, null, isIdent || needsLookup);
}

I had a look in the bug tracker https://bugs.openjdk.java.net/
but didn't
find much in this regard so thought I would post in case it
has come up
before.

I saw some of the css properties are from our application and
some from
e(fx)clipse which I can raise to Tom Schindl separately if it is a
stylesheet issue, however it would appear that for example
-fx-alignment in
a layout VBOX/HBOX component should be valid according to
JavaFX docs.

More generally, is it expected that a property such as
-fx-alignment should
fall into this else {} catch all case, and why does JavaFX try
to parse a
Color by default?

-fx-alignment: center;

Any input much appreciated.

Regards,
Matt

Re: CSSParser Color.parse() for unexpected CSS properties

[David Grieve]

The parser doesn't have any concept of what the property is or value it 
might have. This allows the addition of new properties (such as an user 
might add for their own CSS styles) without having to modify the parser 
to handle them.



On 4/4/18 10:03 AM, Matthew Elliot wrote:

Hi all, (first post).

I was profiling our PROD JavaFX application recently I discovered something
rather peculiar in the CSSParser. (jdk1.8.0_151)

I noticed several hundred IllegalArgumentExceptions on the
JavaApplicationThread where for various unrelated css properties the
CSSParser is trying to parse a color. While the exception is subsequently
caught and swallowed silently doing this hundred of times on this thread is
rather ugly and caused *minor* delays in the application thread.

This happened for alignment, shape, and a few other properties where
no-lookup case was found and it ended on approx. line 900 of the CSSParser
in

colorValueOfString()

with a value like 'center'; clearly no color.

// if the property value is another property, then it needs to be looked up.
boolean needsLookup = isIdent && properties.containsKey(text);
if (needsLookup || ((value = colorValueOfString(str)) == null )) {
 // If the value is a lookup, make sure to use the lower-case text
so it matches the property
 // in the Declaration. If the value is not a lookup, then use str
since the value might
 // be a string which could have some case sensitive meaning
 //
 // TODO: isIdent is needed here because of RT-38345. This
effectively undoes RT-38201
 value = new ParsedValueImpl(needsLookup ? text :
str, null, isIdent || needsLookup);
}

I had a look in the bug tracker https://bugs.openjdk.java.net/ but didn't
find much in this regard so thought I would post in case it has come up
before.

I saw some of the css properties are from our application and some from
e(fx)clipse which I can raise to Tom Schindl separately if it is a
stylesheet issue, however it would appear that for example -fx-alignment in
a layout VBOX/HBOX component should be valid according to JavaFX docs.

More generally, is it expected that a property such as -fx-alignment should
fall into this else {} catch all case, and why does JavaFX try to parse a
Color by default?

-fx-alignment: center;

Any input much appreciated.

Regards,
Matt

Re: CSS reference URL?

[David Grieve]

https://docs.oracle.com/javase/9/docs/api/javafx/scene/doc-files/cssref.html


On 12/8/17 8:46 AM, Johan Vos wrote:

Hi,

Our Pro JavaFX 9 book is about to be published, and it will contain links
to online resources. One very useful resource is the CSS reference. For
JavaFX 8, this was at
https://docs.oracle.com/javase/8/javafx/api/javafx/scene/doc-files/cssref.html
but
I can't find it for JavaFX 9 so far?

- Johan

Re: [10] Review request : JDK-8090462 : CSS performance: Link style helpers together to avoid going through parent chain looking for parent style helpers

[David Grieve]

Ajit,

I have provided some comments in the bug.


On 8/10/17 8:45 AM, Ajit Ghaisas wrote:

Hi Jonathan,

 Request you to review following change :

 Issue : https://bugs.openjdk.java.net/browse/JDK-8090462

 Fix : http://cr.openjdk.java.net/~aghaisas/fx/e8090462/webrev.2/

Regards,
Ajit

Re: CSS id selector with embedded dot

[David Grieve]

Fair enough.

The CSS Reference Guide says " While the JavaFX CSS parser will parse 
valid CSS syntax, it is not a fully compliant CSS parser." Escaped 
characters is a case in point.



On 5/10/17 11:10 AM, Doswald Michael wrote:

On 5/10/17 2:02 PM, David Grieve wrote:

Having an id with a dot is not valid CSS syntax.

 From the spec: " An ID selector contains a "number sign" (U+0023, #)
immediately followed by the ID value, which must be an CSS identifiers."

An identifier is defined here:
https://www.w3.org/TR/CSS21/syndata.html#value-def-identifier. The tldr;
is that an identifier cannot contain a dot.

But in the link you referenced it says:

"Identifiers can also contain escaped characters and any ISO 10646 character as a numeric code (see next item). For 
instance, the identifier "B?" may be written as "B\\?" or "B\26 W\3F"."

Wouldn't that include an escaped dot as a valid character for a CSS identifier?

Re: CSS id selector with embedded dot

[David Grieve]

Having an id with a dot is not valid CSS syntax.

From the spec: " An ID selector contains a "number sign" (U+0023, #) 
immediately followed by the ID value, which must be an CSS identifiers."


An identifier is defined here: 
https://www.w3.org/TR/CSS21/syndata.html#value-def-identifier. The tldr; 
is that an identifier cannot contain a dot.



On 5/10/17 9:23 AM, Jens Auer wrote:

Hi,

I am working on a project which enforces unique FX Id by using a naming convention 
mirroring the hierarchical structure of the controls in the name, delimited by dots. So 
for example, we have a button "myPane.button1". I am not able to select this 
button in a css file. Here is an example program and the css file:

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.VBox;
import javafx.stage.Stage;

public class CssTest extends Application {

 public static void main(final String[] args) {
 Application.launch(args);
 }

 @Override
 public void start(final Stage stage) {
 VBox vbox = new VBox();
 Button b1 = new Button();
 b1.setId("the.button");
 b1.setText("BUTTON1");

 Button b2 = new Button();
 b2.setId("thebutton");
 b2.setText("BUTTON2");

 vbox.getChildren().addAll(b1, b2);
 vbox.getStylesheets().add("stylesheet.css");

 final Scene scene = new Scene(vbox);

 stage.setScene(scene);
 stage.show();
 }
}
The css file is

#the\.button {
 -fx-graphic: url("Keyboard.png");
}

#thebutton {
 -fx-graphic: url("Keyboard.png");
}

As far as I understand the CSS definition the names are valid ids and escaping 
should work here. Is this a limitation in the JavaFX CSS parser?

Best wishes,
Jens

Jens Auer
(Softwareentwicklung)
___
Unternehmensberatung H & D GmbH
Niederlassung Weißenthurm
Werftstr. 5 - 56575 Weißenthurm
Tel.:02637/94238 -110
Fax:02637/94238 -149
jens.a...@h-d-gmbh.de
http://www.h-d-gmbh.de
http://www.h-d-gmbh.de/impressum.html
___

Re: review: Generate bss for all css files, remove TODO

[David Grieve]

The question I have about this change is, do you necessarily want all of 
the css/bss files that may be in that directory in the dist? If someone 
adds a css file in the future, should it be a conscience decision to put 
it into the dist?



On 3/30/17 1:50 PM, David Hill wrote:


Jonathan,
   please review this change automating the CSS to BSS conversion in 
our build
The list of 6 newly converted files as well as the existing ones are 
in the JBS.

So 9 existing plus 6 new = 15.

https://bugs.openjdk.java.net/browse/JDK-8174944
webrev: http://cr.openjdk.java.net/~ddhill/8174944/

Re: Structuring CSS Stylesheets

[David Grieve]

On 8/15/16 10:52 AM, Daniel Glöckner wrote:

We found the culprits by patching the JRE, adding some statistics to
SimpleSelector and CompoundSelector. I was wondering whether there are
easier ways but anyway, it works ;)

This sounds like some code that would be good to share with the community. :)

[DG] Sure thing. It's not too complicated and doesn't use external libs. Any 
hint where I could post it / paste it?
See https://wiki.openjdk.java.net/display/OpenJFX/Community for how to 
contribute

need them, for example our UI component factory would add table.css to a
TableView's list of stylesheets (tv. getStylesheets().add("/path/to/table.css").
The global theme.css would be minimal and only define colors and fonts.

What do you think about this approach? Will this work nicely with caching of

CSS styles in JavaFX?
I think if you are going to go this route, you might want to use
Region#getUserAgentStylesheets() which adds the styles as user-agent styles.
But I don't think it will buy you much in terms of CSS performance.

[DG] We also want to control / override the CSS of standard JavaFX controls 
like TreeTableView. Ideally we don't need to sub class them so we would need to 
use parent. getStylesheets().add(), right?
I doubt that getUserAgentStylesheets() or getStylesheets() is going to 
have much impact. My guess is that having the stylesheets added to the 
scene is going to be your best bet. I say this because the code that 
does the style matching has to combine styles together from 
Region#getUserAgentStylesheets() and Parent#getStylesheets(), whereas 
the styles from scene stylesheets are already combined. You have to 
think of these different sources of styles as sets of styles. When you 
have Region or Parent stylesheets, you have to create a union of those 
styles with the default user-agent stylesheets (e.g., caspian.css). With 
just scene stylesheets, you have just one set (this isn't 100% accurate, 
but close enough for this discussion).



If you the biggest bang for your buck relative to JavaFX CSS performance, avoid
style lookup and relative font sizes.

[DG] Could you explain what you mean by "avoid style lookups"?
You know about styles like '-fx-base' used in caspian.css. You change 
the color for -fx-base and the basic colors of the UI change. This magic 
happens at runtime. So if I have a label in a cell in a table, and it 
has a style "-fx-border-color: -fx-base", JavaFX will - at runtime - try 
to resolve -fx-base into an actual color. It starts at the leaf and 
looks tries to resolve -fx-base. If it can't resolve it, it looks for a 
style in the parent node, and so on up the parent-chain all the way to 
the root node. The worst case scenario, then, is that there are no 
styles that resolve the value until you get to .root.


This is what I mean by 'style lookups'.

Its great stuff (the brainchild of Jasper Potts) because I can change 
the look of my UI just by setting '-fx-base'. But if I were developing a 
UI and I didn't care to let the users of my UI make such changes, I'd go 
through and remove all the lookups in caspian.css (not trivial because 
there are many many lookups - not just -fx-base). Or use a pre-processor 
such as SASS or LESS.


The same sort of lookup happens when you have an em (or other relative 
size) because you need a font or a font-size to complete the 
calculation. In most cases, the lookup for a font or font-size goes all 
the way to .root, where it fails and falls back on Font.getDefault(). 
But its a trade off since em sizes let your UI more easily scale to 
different displays.

Re: Structuring CSS Stylesheets

[David Grieve]

On 8/15/16 9:46 AM, Daniel Glöckner wrote:

Hi,

We recently came across a number of performance issues which were caused by our 
poor CSS.

Our stylesheet contained too many selectors, specifically too many generic selectors 
targeting "common" JavaFX controls (.text, .label etc.).
Make the selectors as specific as possible. Avoid the universal selector 
'*' if you can.


We found the culprits by patching the JRE, adding some statistics to 
SimpleSelector and CompoundSelector. I was wondering whether there are easier 
ways but anyway, it works ;)
This sounds like some code that would be good to share with the 
community. :)


We've meanwhile improved our CSS performance (by making a bunch of selectors 
more specific) but want to re-structure the stylesheets to be more future-proof 
(with even better performance ;)).

Could you quickly comment on the following idea?

Our CSS is already divided into several stylesheets (e.g. table.css, 
some-dialog.css etc.).
These stylesheets are all imported via @import into a global theme.css. 
theme.css is then added to the scene.

We're thinking about adding the individual stylesheets only to nodes which need them, for 
example our UI component factory would add table.css to a TableView's list of stylesheets 
(tv. getStylesheets().add("/path/to/table.css"). The global theme.css would be 
minimal and only define colors and fonts.

What do you think about this approach? Will this work nicely with caching of 
CSS styles in JavaFX?
I think if you are going to go this route, you might want to use 
Region#getUserAgentStylesheets() which adds the styles as user-agent 
styles. But I don't think it will buy you much in terms of CSS performance.


If you the biggest bang for your buck relative to JavaFX CSS 
performance, avoid style lookup and relative font sizes.




Kind regards,
Daniel

Re: How do I read the output of the Pulse Logger?

[David Grieve]

Sometimes the layout might introduce nodes into the scenegraph. If these 
new nodes also need laid out, CSS is applied to those nodes since style 
can affect layout. I would expect CSS overhead to be very small unless 
there are many new nodes being added to the scene 
(https://bugs.openjdk.java.net/browse/JDK-8151756 notwithstanding)


On 3/15/16 12:14 PM, Scott Palmer wrote:

Is there a guideline somewhere that explains how to read the output of the 
Pulse Logger?

For example, what do the two times represent in this PULSE line:

PULSE: 569 [1459ms:270ms]

At first I guessed is that it was PULSE:   [ms:]
but that doesn’t seem to hold up.

What does the first (usually negative) number mean in the Layout Pass line?

T23 (-1563 +1563ms): Layout Pass

T23 (1 +4ms): Layout Pass


I’ve noticed that the output has some notable differences between my Windows 
machine and my Mac. On the Mac I don’t seem to be getting the same sort of CSS 
Pass information.  I get only one “CSS Pass” per pulse and it is almost always 
telling me something near 0ms:

PULSE: 509 [1404ms:286ms]
T23 (-1404 +1404ms): Layout Pass
T23 (0 +1ms): CSS Pass
T23 (1 +6ms): Layout Pass
T23 (7 +4ms): Update bounds
T23 (11 +0ms): Waiting for previous rendering
T23 (11 +0ms): Copy state to render graph

but on Windows I get two CSS Passes, one is usually 0ms, the other makes more 
sense (I’m investigating a performance issue on a Scene with >10k nodes, so 
some notable amount of CSS time is expected.):

PULSE: 2578 [423ms:3362ms]
T35 (-423 +423ms): Layout Pass
T35 (0 +0ms): CSS Pass
T35 (0 +0ms): Layout Pass
T35 (0 +2725ms): CSS Pass
T35 (2725 +402ms): Layout Pass
T35 (3128 +25ms): Update bounds
…

This seems a bit strange, as I would think Layout and CSS would not be platform 
specific. Both systems are running 8u72.
I’m also finding Layout times on the Mac are higher than I expected - maybe 
some CSS time has been rolled in to that log line on the Mac?

Regards,

Scott

Re: reapplyCss() Is called too many times when adding a node hierarchy to the Scene

[David Grieve]

There is (was?) some code in Node or Parent that was supposed to prevent 
this.
Namely, I thought I had it so CSS was applied from the parent before 
applying to the children.


It may also depend on how you add the nodes to the scene.

On 3/11/16 5:18 PM, Scott Palmer wrote:

I think I've discovered a significant performance issue with CSS
processing...

Adding a Node hierarchy to a Scene leads to
javafx.scene.node.setScenes(Scene, SubScene) being called.  This leads a
walk down the Node hierarchy like so:

setScenes
  -> invalidatedScenes
  -> scenesChanged
  -> setScenes// on child Nodes -- recursion
  -> impl_reapplyCSS()
  ->reapplyCss()
 loops over children calling reapplyCss() on each - recursive

The thing to note there is:
* invalidatedScenes decides if it is going to call impl_reapplyCSS()
* invalidatedScenes calls scenesChanged which calls setScenes on all
children which leads to invalidateScenes being called recursively on the
node hierarchy
* invalidatedScenes calls impl_reapplyCSS()

As the setScene call walks down the node hierarchy it gets to a leaf node
and then calls impl_reapplyCSS() which will call reapplyCss() recursively.
Since when reapplyCss() returns the cssFlag for the node will be set back
to UPDATE, so when the parent calls impl_reapplyCSS()  the CSS is
recursively applied to the Nodes that just had CSS applied!

Am I missing something?

I made a quick test case where I add a VBox containing another VBox
containing a Rectangle to the Scene when I press a button.  I can confirm
that reapplyCss() is called THREE times for the Rectangle, twice for the
"middle" VBox, and once on the "top" VBox.

Obviously the deeper the hierarchy the worse this gets.

Scott

Re: including fonts

[David Grieve]

The reason CSS ignores everything but src is that there is no public API 
in Font for providing the additional information.


CSS uses Font.loadFont to load a font from a @font-face src url. See 
com/sun/javafx/css/StyleManager.java


On 1/4/16 2:43 PM, Phil Race wrote:

Hi,

I can't speak authoritatively on the CSS implementation because I am not
familiar with it but here are some thoughts and observations that 
might help.


Suppose you have :
@font-face {
  font-family: RobotoMedium
  src: url("robotomedium.ttf"
}

My reading of the W3C spec. is that the name you specify as font-family
is used by CSS as the family name regardless of the *actual* name of 
the font

but I don't think FX can be working like that if it ignores font-family.

If CSS is ignoring everything except src that seems like
you then need to know for sure yourself what the family + style of the 
font is

and per that bug then use it via fx-font using the actual name+style.
This suggests CSS is loading the font into the list of fonts available 
to be used

by creating fonts directly from JavaFX API.
This seems to be confirmed by you seeing that Font.getFontNames()
reports these.

So you'd need to do the following for both font files
ie.

@font-face {
  font-family: BlahBlahDoesNotMatterApparently
  src: url("robotomedium.ttf")
}


@font-face {
  font-family: BlahBlahDoesNotMatterEither
  src: url("robotomediumitalic.ttf")
}

and reference as :

-fx-font: normal normal 12 "Roboto Medium"
-fx-font: italic normal 12 "Roboto Medium"

If this does not work then I don't know what CSS might be doing in its 
lookup.
The comment about only the last one loaded being available does not 
add up to me

unless CSS is doing some buggy filtering or remembering of its own.
Perhaps explicitly specifying "normal" will fix that.

-phil.

On 01/04/2016 12:08 AM, Tom Eugelink wrote:

No problem, thanks for the suggestion!

What I expect to be the cause is that the attributes in @font-face, 
specifying if a font is italic or not, are not supported. And they 
probably aren't populated based on the TTF metadata either. But 
before I dive too deep, maybe someone can prevent me from swimming in 
the wrong direction.


Tom


On 4-1-2016 00:02, cogmission (David Ray) wrote:

I guess I was assuming the "ideal"/expected behavior applied? Sorry...

On Sun, Jan 3, 2016 at 10:14 AM, Tom Eugelink > wrote:


Hi David,

Which would assume that if I specify no keywords, then it should 
take the normal version. It does not. Whatever version is loaded 
last is used.


Tom



On 3-1-2016 17:09, cogmission (David Ray) wrote:

Hi Tom,

I Believe in CSS, once you establish the family you can 
access the sub-types via type keywords?

...via

-fx-font-weight: bold,bolder etc.
-fx-font-style: plain, italic

Cheers,
David

On Sun, Jan 3, 2016 at 8:52 AM, Tom Eugelink  >> wrote:


Addendum:

If I list the font families using Font.getFamilies() I 
get "Roboto Medium" once, given that both TTF files are added using 
@font-face. But if I examine Font.getFontNames() I get separate 
entries for "Roboto Medium" and "Roboto Medium Italic". Closer 
examination of the font loading reveals that indeed each font has 
its own distinct name and some fonts shared the same family name. 
That makes sense.


The thing is that in CSS -as far as I can see- fonts can 
only accessed through its family name, not its own name.


Tom



On 3-1-2016 11:21, Tom Eugelink wrote:

I'm currently including Google's Roboto font in 
JFXtras and making it easily available to other users. I noticed 
that the font-family attribute in font-face is ignored, and you have 
to use the name as it is specified in the TTF file. I found 
https://bugs.openjdk.java.net/browse/JDK-8094516 which says "/Please 
note that all @font‑face descriptors are ignored except for the src 
descriptor./" That pretty much explains what is going on.


Now, Roboto comes in different styles, condensed, 
bold, etc, but also italic. However, italic is a separate TTF file, 
so you have a Roboto-Medium.ttf and a Roboto-MediumItalic.ttf. The 
name of the font inside these two TTF files is the same, so when I 
use "font-family: 'Roboto Medium'" whatever ever font is defined 
last by font-face is used, and the other is not accessible.


My question is: is the way Roboto does Italic, with 
the same font name in the TTF file, a bug of Roboto, or is this common?


Tom





-- /With kind regards,/
David Ray
Java Solutions Architect
*Cortical.io *
Sponsor of: HTM.java 
d@cortical.io  

Re: Constant resetting to initial-state when adding/remove styleclasses

[David Grieve]

Adding/removing style-classes is simply bad practice. And not just in 
JavaFX. It is better to use pseudo-class state.


When the style-class changes, the set of styles that match a node can, 
and is very likely to, change. The css implementation 're-applies' css 
to the node and its children by finding the new set of matching styles, 
resetting all properties that were set by css to their defaults, and 
then setting the properties according to the new set of matching styles. 
With pseudo-class state, the only thing that happens is the set of 
styles that match the pseudo-class state are applied. Much less overhead.


That said, there are plenty of places where the css implementation could 
be better optimized. This use-case is certainly one of them.


On 12/22/15 1:15 AM, Tom Schindl wrote:

Hi,

While debugging some code I attached a listener to a property and
noticed that whenever a style-class is added to the control or even
worse somewhere in the parent hierarchy that FX resets the value to its
initial state (Node#reapplyCss & CssStyleHelper) only to set it back to
it's real value with the next CSS-Pass triggered by the next pulse.

I don't want to imagine if this happens with many value set via CSS and
eg adding/remove a styleclass to the scene root. Is this behavior really
by design like this?

You can try that yourself with the attached program below and using the
css at the end. I'm writing this because of Kevins request what the team
should invest time to because of Java9 delays and frankly all of those
bugs/features sound relevant and interesting but JavaFX performance
(most important CSS-Performance) is still miles away from eg browsers
who are the main competitors.

It doesn't help me to get an java.awt.Desktop replacement if my
input-forms do not render in a decent time frame - I would even say
rendering them in 2015 most be almost instant.

Tom


package application;

import javafx.application.Application;
import javafx.stage.Stage;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.BorderPane;
import javafx.scene.layout.HBox;
import javafx.scene.layout.StackPane;


public class Main extends Application {
@Override
public void start(Stage primaryStage) {
try {
BorderPane root = new BorderPane();

StackPane p = new StackPane();
p.getStyleClass().add("test-css");
p.maxWidthProperty().addListener( (o, ol, ne) -> {
System.err.println("Modified : " + ol + " " + 
ne);
Thread.dumpStack();
});

root.setCenter(p);

HBox box = new HBox();

{
Button b = new Button("Modify Pane CSS");
b.setOnAction( e -> 
p.getStyleClass().add("dummy"));
box.getChildren().add(b);
}

{
Button b = new Button("Modify Root CSS");
b.setOnAction( e -> {
root.getStyleClass().add("dummy");
});
box.getChildren().add(b);
}

root.setBottom(box);

Scene scene = new Scene(root,400,400);

scene.getStylesheets().addAll(getClass().getResource("application.css").toExternalForm());
primaryStage.setScene(scene);
primaryStage.show();
} catch(Exception e) {
e.printStackTrace();
}
}

public static void main(String[] args) {
launch(args);
}
}



.test-css {
-fx-max-width: 300;
}

Re: [Review request] 8145143: Promote Image.impl_getUrl() to public API as Image.getUrl()

[David Grieve]

I believe the url might be used in the CSS engine for caching images 
loaded from .css files. If the css image cache is made public (I don't 
know if that is planned, but it should be considered), then this API 
will matter.


On 12/10/15 4:39 PM, Kevin Rushforth wrote:
That's an interesting question. We haven't used Optional for such 
cases except the return value of Dialog showAndWait. Wrapping the URL 
in an Optional is more self-documenting, but perhaps less convenient 
if you know that it is non-null (and basically the same if you don't 
know, since this doesn't seem like something you would do anything 
with other than asking "is it valid").


Another interesting question: how useful is this API? It was on the 
list of impl_* method that Jonathan and I felt would be worth making 
public API out of, but I don't know how prevalent its use is?


-- Kevin


Tom Schindl wrote:
As i see it the url is optional so wouldn't make sense to return 
Optional to make this more explicit?


Tom

Von meinem iPhone gesendet

Am 10.12.2015 um 21:54 schrieb Jonathan Giles 
:


Hi Chien, Kevin,

Please can you review the following JBS issue (and attached patch):

https://bugs.openjdk.java.net/browse/JDK-8145143

As the subject line states, this issue proposes to promote the 
Image.impl_getUrl() method to Image.getUrl(), so that it is public API.


--


-- Jonathan

Re: Why are style classes stored in a List instead of a Set?

[David Grieve]

The bottom line answer is poor design of the API. There has been 
discussion about how to handle this, such as having a List 
implementation that rejects duplicates (but that would break the List 
contract), or adding new API.


You might be interested to know that, on the CSS implementation side, 
this ListString is turned into a SetStyleClass.


On 5/21/15 1:17 AM, Roland C wrote:

I was recently toying around with CSS in JavaFX and noticed that I got the
same style multiple times in the style list of my node.

Since the order of the styles is defined by the order in the css file and
not by the order of the list that getStyleClass() of a node returns, I was
wondering if there is a special reason for that.

Example:

application.css

.bg-color-1 {
 -fx-background-color:red; }.bg-color-2 {
 -fx-background-color:green;}

Main.java

public class Main extends Application {
 @Override
 public void start(Stage primaryStage) {
 try {
 BorderPane root = new BorderPane();

 root.getStyleClass().add( bg-color-1);
 root.getStyleClass().add( bg-color-2);

 Scene scene = new Scene(root,400,400);
 
scene.getStylesheets().add(getClass().getResource(application.css).toExternalForm());
 primaryStage.setScene(scene);
 primaryStage.show();
 } catch(Exception e) {
 e.printStackTrace();
 }
 }

 public static void main(String[] args) {
 launch(args);
 }}

It doesn't matter if you write

 root.getStyleClass().add( bg-color-1);
 root.getStyleClass().add( bg-color-2);

or change the order to

 root.getStyleClass().add( bg-color-2);
 root.getStyleClass().add( bg-color-1);

The used style will always be the last in the css file, i. e. bg-color-2.

*Question*

Why is a List used instead of a Set? A list is less performing than a Set
and it clutters the code if you always have to make a contains-check first.


Thank you very much!

Re: @import in CSS

[David Grieve]

Yes. The details are in 
http://www.w3.org/TR/CSS2/cascade.html#cascading-order, but here is the 
excerpt that matters:  if two declarations have the same weight, origin 
and specificity, the latter specified wins. Declarations in imported 
style sheets are considered to be before any declarations in the style 
sheet itself.


On 4/9/15 1:42 AM, Tom Eugelink wrote:
Does the order in which things appear in a CSS have influence on the 
behavior?


Tom


On 8-4-2015 23:22, David Grieve wrote:
The spec says that if there is an @import it has to appear first 
before any rule, except @charset, if present.


On 4/8/15 5:12 PM, Tom Eugelink wrote:
I'm currently porting and reworking some gauges from Enzo to 
JFXtras. One of things that gets reworked involves that all gauges 
will have custom colored segments. These segments can be preset 
using colorschemes (e.g. green to red in 10 steps), so the CSS for 
these colors are shared over all gauges. I tried using @import, but 
since it is required to be the first lines in a CSS, I'm suspecting 
that is the reason it is not working as expected.


Is there any intention to allow these imports to occur half way in a 
file? Placeholder-and-replace alike (#include), so to speak.


Tom

Re: @import in CSS

[David Grieve]

Take -fxx-needle-color (from SimpleMetroArcGauge.css) as an example. Its 
declaration appears in the .SimpleMetroArcGauge rule and is then used in 
the -fx-fill declaration of the .needle rule. The CSS parser is pretty 
dumb. It collects up the property names as it parses and if any of those 
property names appears a a property value, it marks the property value 
as needing to be looked up. Then, at run time, if a property has a value 
that needs to be looked up, the CSS engine goes from the node up to the 
root looking for a declaration that resolves the property to a real 
value. Anyway, the point is, you can't have forward references for these 
lookup values.


Note also that the .needle node has to be a .SimpleMetroArcGauge or a 
child of a .SimpleMetroArcGauge for the lookup to work. In modena.css, 
for example, all of the lookup properties are declared in the .root rule 
so this isn't an issue. You could do the same or be more explicit in 
your rules by saying, e.g.,


.needle { -fx-fill: orange; }
.SimpleMetroArcGauge .needle { -fx-fill: -fxx-needle-color; }

In this way, a needle that is a child of .SimpleMetroArcGauge will pick 
up -fxx-needle-color, but a .needle that is not will be orange.



On 4/9/15 11:11 AM, Tom Eugelink wrote:
Hm. That would mean this should work, but it does not. So instead of 
moving the lines 216 and up to a separate file, I moved them to the 
front, but the colorschemes are not working then. The lines must be 
after the first (.SimpleMetroArcGauge) block. I don't understand why 
this matters, if it is declaration based.


https://github.com/JFXtras/jfxtras-labs/blob/8.0/src/main/resources/jfxtras/labs/internal/scene/control/gauge/linear/SimpleMetroArcGauge.css 




On 9-4-2015 13:34, David Grieve wrote:
Yes. The details are in 
http://www.w3.org/TR/CSS2/cascade.html#cascading-order, but here is 
the excerpt that matters:  if two declarations have the same weight, 
origin and specificity, the latter specified wins. Declarations in 
imported style sheets are considered to be before any declarations in 
the style sheet itself.


On 4/9/15 1:42 AM, Tom Eugelink wrote:
Does the order in which things appear in a CSS have influence on the 
behavior?


Tom


On 8-4-2015 23:22, David Grieve wrote:
The spec says that if there is an @import it has to appear first 
before any rule, except @charset, if present.


On 4/8/15 5:12 PM, Tom Eugelink wrote:
I'm currently porting and reworking some gauges from Enzo to 
JFXtras. One of things that gets reworked involves that all gauges 
will have custom colored segments. These segments can be preset 
using colorschemes (e.g. green to red in 10 steps), so the CSS for 
these colors are shared over all gauges. I tried using @import, 
but since it is required to be the first lines in a CSS, I'm 
suspecting that is the reason it is not working as expected.


Is there any intention to allow these imports to occur half way in 
a file? Placeholder-and-replace alike (#include), so to speak.


Tom

Re: @import in CSS

[David Grieve]

The spec says that if there is an @import it has to appear first before 
any rule, except @charset, if present.


On 4/8/15 5:12 PM, Tom Eugelink wrote:
I'm currently porting and reworking some gauges from Enzo to JFXtras. 
One of things that gets reworked involves that all gauges will have 
custom colored segments. These segments can be preset using 
colorschemes (e.g. green to red in 10 steps), so the CSS for these 
colors are shared over all gauges. I tried using @import, but since it 
is required to be the first lines in a CSS, I'm suspecting that is the 
reason it is not working as expected.


Is there any intention to allow these imports to occur half way in a 
file? Placeholder-and-replace alike (#include), so to speak.


Tom

Re: Debugging CSS

[David Grieve]

You should file an issue in jira for this.

On 4/6/15 3:31 AM, Tom Eugelink wrote:

On 6-4-2015 00:58, David Grieve wrote:



On 4/5/15 3:56 AM, Tom Eugelink wrote:
I have another interesting behavior involving CSS. The gauge has a 
text representation of the value of the needle, which can be 
formatted using DecimalFormat. The format string can be set with a 
styleable property.


In the example this property is set, via setStyle(), to something 
with a unit postfix, e.g. ##0.0W so the gauge will show watts. 
This works. But as soon as totally unrelated classes are removed 
from the gauge, the styleable property reverts to its initial value, 
but the style string is unchanged!


This behavior is introduced in 8u20, in 8u00 it works as intended.

And in 8u40?


The behavior is still present in 8u40. It is easy to see; checkout 
JFXtras labs from github, open the project in you favorite IDE, and 
start the SimpleMetroArcGaugeTrail1 class. It's the gauge with the W 
in the text, at first :-)


Tom

Re: Debugging CSS

[David Grieve]

On 4/5/15 3:56 AM, Tom Eugelink wrote:
I have another interesting behavior involving CSS. The gauge has a 
text representation of the value of the needle, which can be formatted 
using DecimalFormat. The format string can be set with a styleable 
property.


In the example this property is set, via setStyle(), to something with 
a unit postfix, e.g. ##0.0W so the gauge will show watts. This 
works. But as soon as totally unrelated classes are removed from the 
gauge, the styleable property reverts to its initial value, but the 
style string is unchanged!


This behavior is introduced in 8u20, in 8u00 it works as intended.

And in 8u40?


Tom

On 4-4-2015 08:14, Tom Eugelink wrote:
After loads of trail and error I pinned it down to the fact that 
scaling of the node in question was not taking into account when 
positioning it; it is centered and I use its width to do that, but it 
was the width-before-scaling. So it was a miracle it was in the right 
place at all. What really would be needed here (and I think anyone 
who has done HTML with CSS will agree) is a 
which-property-is-set-by-which-CSS-class-and-file, like the debug 
view in browsers. Does the CSS engine keep track of this information?


When it comes time to pick the style for a property, the CSS engine does 
not know which CSS file a property came from. The APIs mentioned below 
are all you have when it comes to finding what styles apply to a node. 
These methods are, in fact, the methods that Scene Builder uses for its 
CSS analyzer.

Tom


On 3-4-2015 22:19, David Grieve wrote:
When you add or remove style-classes, CSS for the node (and all its 
children) is totally re-calculated. This means that cached data for 
that node is tossed out and the node is styled from scratch, as if 
it were just added to the scene-graph.


You are much better off using pseudo-class state for what you are 
trying to do. Changes in pseudo-class state just causes evaluation 
of what styles are applied in that state, which is relatively low 
overhead compared to re-calculating styles.


To debug, you should try using Scenic View 
(http://fxexperience.com/scenic-view/)


You can also use the Node API MapStyleableProperty?,ListStyle 
impl_findStyles(MapStyleableProperty?,ListStyle styleMap). 
Note that this is deprecated API


On 4/3/15 2:13 PM, Tom Eugelink wrote:
One addition: the move happens if, for example, segment0-active 
is added to the skinnable. Even if that class is empty or even not 
defined in the CSS.


Tom

On 3-4-2015 19:48, Tom Eugelink wrote:
I'm pushing the envelope a bit -I think- concerning the use of 
CSS. I have setup a control (gauge) in such a way that, depending 
on the position of the needle, certain CSS classes are added or 
removed from the control. For example a errorSegment-active 
class if the value comes into the 90-100 value in a 0-100 gauge. 
In this class a CSS variable -fx-error-indicator-visibility is set 
to visible and that again shows some kind of indicator on the 
gauge. Works great.


What is strange is when this class is assigned to the control, a 
totally unrelated node (the value in the needle) suddenly moves 
out of position. I do not understand this, because the CSS only 
involves colors and visibility, never any transformation.
https://github.com/JFXtras/jfxtras-labs/blob/8.0/src/main/resources/jfxtras/labs/internal/scene/control/gauge/linear/SimpleMetroArcGauge.css 



Is there any way to debug what CSS settings are applied to nodes? 
I really would like to find out what causes that node to move.


Tom

Re: Debugging CSS

[David Grieve]

When you add or remove style-classes, CSS for the node (and all its 
children) is totally re-calculated. This means that cached data for that 
node is tossed out and the node is styled from scratch, as if it were 
just added to the scene-graph.


You are much better off using pseudo-class state for what you are trying 
to do. Changes in pseudo-class state just causes evaluation of what 
styles are applied in that state, which is relatively low overhead 
compared to re-calculating styles.


To debug, you should try using Scenic View 
(http://fxexperience.com/scenic-view/)


You can also use the Node API MapStyleableProperty?,ListStyle 
impl_findStyles(MapStyleableProperty?,ListStyle styleMap). Note 
that this is deprecated API


On 4/3/15 2:13 PM, Tom Eugelink wrote:
One addition: the move happens if, for example, segment0-active is 
added to the skinnable. Even if that class is empty or even not 
defined in the CSS.


Tom

On 3-4-2015 19:48, Tom Eugelink wrote:
I'm pushing the envelope a bit -I think- concerning the use of CSS. I 
have setup a control (gauge) in such a way that, depending on the 
position of the needle, certain CSS classes are added or removed from 
the control. For example a errorSegment-active class if the value 
comes into the 90-100 value in a 0-100 gauge. In this class a CSS 
variable -fx-error-indicator-visibility is set to visible and that 
again shows some kind of indicator on the gauge. Works great.


What is strange is when this class is assigned to the control, a 
totally unrelated node (the value in the needle) suddenly moves out 
of position. I do not understand this, because the CSS only involves 
colors and visibility, never any transformation.
https://github.com/JFXtras/jfxtras-labs/blob/8.0/src/main/resources/jfxtras/labs/internal/scene/control/gauge/linear/SimpleMetroArcGauge.css 



Is there any way to debug what CSS settings are applied to nodes? I 
really would like to find out what causes that node to move.


Tom

Re: Event when CSS is applied

[David Grieve]

On 2/17/15 8:02 AM, Tom Eugelink wrote:
I have a skin (of a control) that centers a Text node. This Text node 
can be styled via CSS, so this styling is a factor when centering. 
because larger font means wider text.


The centering works perfectly, the only problem is figuring out when 
to center the node. At the moment I'm centering the node on every 
layoutChildren call of the skin, but this is way to often, because 
after applying the CSS chances are very low that the node will need to 
be repositioned.


Basically I would like to be informed when the styling of a node has 
been applied or changed. Is there some place that can provide this 
information?


Not in general, no. But you can add a listener to a property that is 
styled by CSS and react to the change. You might add a listener to the 
Text node's fontProperty, for example. Clearly this isn't an all-purpose 
solution. Another approach is to hold onto the bounds (or maybe just the 
pref width and height) of the child node. If the old bounds doesn't 
equal the new bounds, then recenter.

Re: Event when CSS is applied

[David Grieve]

On 2/17/15 1:30 PM, Tom Eugelink wrote:
The control is a codewise polish up one of Gerrit's gauges (with 
permission!) and pulled into JFXtras (with tests and all). For an idea 
on what we are talking about:

https://www.youtube.com/watch?v=RH5X1uBu1d8

The process of centering the Text in that circle is a bit more complex.
1. The value may vary between a min and max value.
2. I want the Text to automatically utilize the maximum available 
space, but not change size when a longer or shorter text is shown.


To do this I have two additional Text nodes that have the same styling 
as the Text node (so these are on the scene, but not visible, 
otherwise CSS is not applied). These two text nodes get the maximum 
and minimum possible value set. Then on these two some pythagoras is 
applied and in that way one can determine the scale factor so that the 
value will never be rendered outside of the circle. Then the actual 
to-be-rendered value can be placed into the Text node and positioned 
in the centre of the circle.


The problem is that a lot of these calculations depend on the CSS 
styling. What font is set? Bold or not? So I can only do these 
calculcation after the CSS has been applied. This unfortunately is not 
yet the case when the skin is instantiated. This means that if I do 
not used the layoutChildren, the initial presentation is totally off, 
untill the first min/max/value is set.

Have you looked at the javadoc for Node#applyCss()?



So I would like to know when the CSS is applied to do the initial 
calculations. After that only when CSS, min or max changes is a 
recalculation required.


Tom



On 17-2-2015 19:05, Tomas Mikula wrote:

Hi Tom,

suppose you have such an event and can tell whether CSS of your Text
has changed. But is changed CSS the only time you want to re-position
the Text? I guess you also need to re-position it when the size of the
parent changes. I imagine the logic for determining whether you need
to re-position the Text or not can get quite complicated.

Why is it a problem that you reposition the Text too often?

I imagine, and someone please correct me if I'm wrong, that when you
ask for text.prefWidth(-1), you get a cached prefWidth from the last
call, if no properties of Text have changed since the last call to
prefWidth. I also suppose, and again correct me if I'm wrong, that if
you resizeRelocate the Text to the exact same position and size as it
already has, it does not incur any additional operations down the road
compared to not calling resizeRelocate at all. So my conclusion is
that repositioning the Text to the same place is not more expensive
than checking whether the Text needs to be repositioned.

Regards,
Tomas

On Tue, Feb 17, 2015 at 10:14 AM, Tom Eugelink t...@tbee.org wrote:

Registering to fontProperty works, but potentially requires a lot of
listeners on every property that may affect the size, like effect, 
scale,
etc. So I'm leaving it in layoutChildren for now; better once to 
many than

not often enough.

Would adding such an event be a big change?




On 17-2-2015 14:50, David Grieve wrote:


On 2/17/15 8:02 AM, Tom Eugelink wrote:
I have a skin (of a control) that centers a Text node. This Text 
node can
be styled via CSS, so this styling is a factor when centering. 
because

larger font means wider text.

The centering works perfectly, the only problem is figuring out 
when to

center the node. At the moment I'm centering the node on every
layoutChildren call of the skin, but this is way to often, because 
after

applying the CSS chances are very low that the node will need to be
repositioned.

Basically I would like to be informed when the styling of a node 
has been
applied or changed. Is there some place that can provide this 
information?



Not in general, no. But you can add a listener to a property that is
styled by CSS and react to the change. You might add a listener to 
the Text

node's fontProperty, for example. Clearly this isn't an all-purpose
solution. Another approach is to hold onto the bounds (or maybe 
just the
pref width and height) of the child node. If the old bounds doesn't 
equal

the new bounds, then recenter.

Re: CSS under 1.8.0_40 not identical to 31 or older

[David Grieve]

Create an issue in JIRA and include a simple example that reproduces the 
issue.


On 2/4/15 4:13 PM, Tom Eugelink wrote:
I've just now ran JFXtras Samples under the latest 1.8.0_40 and it 
does not render identical as when run under 1.8.0_31, some CSS rules 
are not applied. Samples is easily downloaded from here 
(http://jfxtras.org/resources/java/jfxtras-labs-samples-8.0-r4-SNAPSHOT-shadow.jar) 
and started simply with java -jar.


When run under 1.8.0_31 or older, the LocalDateTimeTextfieldSample 
shows a textfield with a popup button. When the button is pressed a 
popup is shown, with a gradient as the background and both an ok and 
cancel icon in the right top. The exact same jar under 1.8.0_40 does 
not show the gradient nor the two icons.


LocalDateTimeTextfield under water uses CalendarTextField, so the code 
for this is in the calendar based control:
https://github.com/JFXtras/jfxtras/blob/8.0/jfxtras-controls/src/main/java/jfxtras/internal/scene/control/skin/CalendarTextFieldSkin.java 

https://github.com/JFXtras/jfxtras/blob/8.0/jfxtras-controls/src/main/resources/jfxtras/internal/scene/control/CalendarTextField.css 



Interesting are the lines starting at 351 in the skin, which do:
Popup lPopup = new Popup();
...
BorderPane lBorderPane = new BorderPane();
lBorderPane.getStyleClass().add(this.getClass().getSimpleName() + 
_popup); // this amounts to CalendarTextFieldSkin_popup 

...
lPopup.getContent().add(lBorderPane);

This no longer results in applying the background colors as defined in 
the css file on line 12.

.CalendarTextFieldSkin_popup {
-fx-background-color: -fx-shadow-highlight-color, 
-fx-outer-border, -fx-inner-border, -fx-body-color;

-fx-background-insets: 0 0 -1 0,0,1,2;
-fx-background-radius: 5,5,4,3;
-fx-padding: 0.77em 0.73em 0.75em 0.73em;
-fx-text-fill: -fx-text-base-color;
}

Neither are the two in the css defined icons applied to the ImageViews.

Is this intentional or a bug?

Tom

Re: CSS under 1.8.0_40 not identical to 31 or older

[David Grieve]

Thanks, Tom.  Send me the source and I'll attach it on your behalf.

On 2/5/15 1:08 PM, Tom Eugelink wrote:
Luckily I had a test project still available from a previous CSS 
issue, so a simple test was easily created.

https://javafx-jira.kenai.com/browse/RT-39995

Now I only need a way to attach a file to that issue...

Tom


On 5-2-2015 16:47, David Grieve wrote:
Create an issue in JIRA and include a simple example that reproduces 
the issue.


On 2/4/15 4:13 PM, Tom Eugelink wrote:
I've just now ran JFXtras Samples under the latest 1.8.0_40 and it 
does not render identical as when run under 1.8.0_31, some CSS rules 
are not applied. Samples is easily downloaded from here 
(http://jfxtras.org/resources/java/jfxtras-labs-samples-8.0-r4-SNAPSHOT-shadow.jar) 
and started simply with java -jar.


When run under 1.8.0_31 or older, the LocalDateTimeTextfieldSample 
shows a textfield with a popup button. When the button is pressed a 
popup is shown, with a gradient as the background and both an ok and 
cancel icon in the right top. The exact same jar under 1.8.0_40 does 
not show the gradient nor the two icons.


LocalDateTimeTextfield under water uses CalendarTextField, so the 
code for this is in the calendar based control:
https://github.com/JFXtras/jfxtras/blob/8.0/jfxtras-controls/src/main/java/jfxtras/internal/scene/control/skin/CalendarTextFieldSkin.java 

https://github.com/JFXtras/jfxtras/blob/8.0/jfxtras-controls/src/main/resources/jfxtras/internal/scene/control/CalendarTextField.css 



Interesting are the lines starting at 351 in the skin, which do:
Popup lPopup = new Popup();
...
BorderPane lBorderPane = new BorderPane();
lBorderPane.getStyleClass().add(this.getClass().getSimpleName() + 
_popup); // this amounts to CalendarTextFieldSkin_popup 

...
lPopup.getContent().add(lBorderPane);

This no longer results in applying the background colors as defined 
in the css file on line 12.

.CalendarTextFieldSkin_popup {
-fx-background-color: -fx-shadow-highlight-color, 
-fx-outer-border, -fx-inner-border, -fx-body-color;

-fx-background-insets: 0 0 -1 0,0,1,2;
-fx-background-radius: 5,5,4,3;
-fx-padding: 0.77em 0.73em 0.75em 0.73em;
-fx-text-fill: -fx-text-base-color;
}

Neither are the two in the css defined icons applied to the ImageViews.

Is this intentional or a bug?

Tom

Re: switching skins at runtime

[David Grieve]

Yes, it is allowed. But know that there is some code in setSkin that 
prevents setting a skin that is either instance equal or the same class.


On 12/23/14, 6:27 AM, Tom Eugelink wrote:
Is it allowed / supported to execute setSkin with a new skin on a 
control that is part of a scene?


Tom

Re: CSS warning

[David Grieve]

JavaFX CSS has a 'lookup' feature that allows you to declare the value 
of a property as another property. For example, the -fx-base property 
defines the base color of the modena theme (the same goes for caspian). 
When a css value is calculated, these looked-up properties have to be 
resolved to a real value. The code looks for matching styles starting 
with the current node and going up the parent chain to the root of the 
scene-graph until it finds a value that doesn't need to be further 
resolved.  If the value isn't resolved, then this message is printed out.


Resolving a lookup value is dependent on a node's parents having already 
been processed by CSS. If, for example, -fx-base is in .root and the 
root of the scene-graph hasn't been processed by CSS, the root node will 
not have any styles and the lookup will fail. The CSS code tries to 
ensure that CSS is always processed from the root down and also tries to 
ensure that the CSS state of parent nodes is not dirty when CSS is 
processed on a child node.


When new styles are added to the scene-graph, from adding a stylesheet 
to the scene or adding a user-agent stylesheet, CSS is reapplied to the 
scene-graph. This means that all the matching styles and calculated 
values are thrown away and re-evaluated from scratch. In 8u20, adding a 
stylesheet to a control via the Control method getUserAgentStylesheet() 
will cause this to happen. So I think what is happening here is that the 
getUserAgentStylesheet() call happens in the middle of CSS being 
processed on the Control; thus, the CSS for the parent nodes of the 
control will all be tossed out and the lookups will fail. This all 
settles out in the next CSS pass, which is why you don't see an issue 
with the look.


There was some work done in 8u40 improve the handling of reapplying CSS. 
There were also some changes to getUserAgentStylesheet() so that it only 
affects the control and not the whole scene-graph. Try 8u40 and see if 
that doesn't help. If you still get these warnings on 8u40, then please 
create a bug in jira.


On 10/21/14, 2:10 AM, Tom Eugelink wrote:
Has anyone every figured out what the cause is of these CSS warnings I 
get? They do not seem to influence the look at all, and since I copied 
the styling from moderna.css, they do not seem to be valid either. I 
suspect it may have to do with a different handling of CSS and that I 
cannot reuse stuff defined in moderna? Because if I take the first 
error; -fx-focus-color is defined in moderna.css.


Tom

okt 21, 2014 8:02:42 AM javafx.scene.CssStyleHelper calculateValue
WARNING: Could not resolve '-fx-focus-color' while resolving lookups 
for '-fx-background-color' from rule '*.ListSpinnerSkin' in stylesheet 
file:/C:/Users/user/Documents/jfxtras/jfxtras-controls/_build/jfxtras/internal/scene/control/ListSpinner.css

okt 21, 2014 8:02:42 AM javafx.scene.CssStyleHelper calculateValue
WARNING: Could not resolve '-fx-text-background-color' while resolving 
lookups for '-fx-text-fill' from rule '*.label' in stylesheet 
jar:file:/C:/Program%20Files%20(x86)/Java/jre1.8.0_20/lib/ext/jfxrt.jar!/com/sun/javafx/scene/control/skin/modena/modena.bss

okt 21, 2014 8:02:42 AM javafx.scene.CssStyleHelper calculateValue
WARNING: Could not resolve '-fx-text-background-color' while resolving 
lookups for '-fx-text-fill' from rule '*.label' in stylesheet 
jar:file:/C:/Program%20Files%20(x86)/Java/jre1.8.0_20/lib/ext/jfxrt.jar!/com/sun/javafx/scene/control/skin/modena/modena.bss

okt 21, 2014 8:02:42 AM javafx.scene.CssStyleHelper calculateValue
WARNING: Could not resolve '-fx-focus-color' while resolving lookups 
for '-fx-background-color' from rule '*.ListSpinnerSkin' in stylesheet 
file:/C:/Users/user/Documents/jfxtras/jfxtras-controls/_build/jfxtras/internal/scene/control/ListSpinner.css

okt 21, 2014 8:02:42 AM javafx.scene.CssStyleHelper calculateValue
WARNING: Could not resolve '-fx-text-background-color' while resolving 
lookups for '-fx-text-fill' from rule '*.label' in stylesheet 
jar:file:/C:/Program%20Files%20(x86)/Java/jre1.8.0_20/lib/ext/jfxrt.jar!/com/sun/javafx/scene/control/skin/modena/modena.bss

okt 21, 2014 8:02:42 AM javafx.scene.CssStyleHelper calculateValue
WARNING: Could not resolve '-fx-text-background-color' while resolving 
lookups for '-fx-text-fill' from rule '*.label' in stylesheet 
jar:file:/C:/Program%20Files%20(x86)/Java/jre1.8.0_20/lib/ext/jfxrt.jar!/com/sun/javafx/scene/control/skin/modena/modena.bss

okt 21, 2014 8:02:42 AM javafx.scene.CssStyleHelper calculateValue
WARNING: Could not resolve '-fx-text-background-color' while resolving 
lookups for '-fx-text-fill' from rule '*.label' in stylesheet 
jar:file:/C:/Program%20Files%20(x86)/Java/jre1.8.0_20/lib/ext/jfxrt.jar!/com/sun/javafx/scene/control/skin/modena/modena.bss

okt 21, 2014 8:02:42 AM javafx.scene.CssStyleHelper calculateValue
WARNING: Could not resolve '-fx-accent' while resolving lookups for 
'-fx-text-fill' from rule '*.CalendarPickerControlSkin 

Re: Classpath-relative URLs in CSS

[David Grieve]

What version of JavaFX? Would you mind creating a bug for this?

Other responses in-line.

On 10/15/14, 6:38 AM, Werner Lehmann wrote:

Hi David,

classpath-relative URLs in CSS do not seem to work, unfortunately. For 
example,


  -fx-background-image: url(/mint/report_16x16.png);

has no effect. Relative addressing does work. Looks to me as if there 
is a bug in com.sun.javafx.css.converters.URLConverter.resolve. 
Basically it seems to work like this:


- if url is absolute (has a scheme, e.g. http), use it verbatim
- if stylesheet url is present, use that to resolve the image url
- otherwise go to contextclassloader

I don't get to the last step because the stylesheet url in the second 
step is always present. Am I seeing things, or is there another way to 
do this?
Two pieces of information are passed into the converter. The first is 
the value that was given in the style, e.g., /mint/report_16x16.png. 
The second is the URL of the stylesheet as determined when the 
stylesheet is loaded. The stylesheet URL may be null, as would be the 
case for an in-line style.


By the way, even with relative addressing I still cannot access images 
during debugging in Eclipse if the stylesheet is in a different 
Eclipse project than the referenced image resource. This really hurts 
modularization and resource reuse (or I am forced to do this in code). 
Any idea about that?
If the resource is copied over to the build directory that eclipse uses 
on the class-path, then there shouldn't be a problem.


Rgds
Werner


On 01.06.2012 04:03, David Grieve wrote:

In the current implementation, absolute paths without a scheme are
not resolved relative to the class path. I have created RT-21967 to
track the issue.

Re: WARNING: CSS Error parsing

[David Grieve]

There is no short-hand for border in JavaFX.  You need to use both 
-fx-border-color and -fx-border-style
See 
http://docs.oracle.com/javase/8/javafx/api/javafx/scene/doc-files/cssref.html


On 10/15/14, 3:53 PM, Peter Penzov wrote:

Hi,
I tested Java 8u40. I get error when I run this part of the code:

setStyle(-fx-background-color: linear-gradient(to bottom, #FAFAFA,
#EAEAEA);
 +  -fx-border: 2px solid; -fx-border-color: white;);

X 15, 2014 10:33:53 PM com.sun.javafx.css.parser.CSSParser declaration
WARNING: CSS Error parsing '*{-fx-background-color: linear-gradient(to
bottom, #FAFAFA, #EAEAEA); -f
x-border: 2px solid; -fx-border-color: white;}: expected series of size
while parsing '-fx-border'
  at [1,82]


Is this a bug or css code is wrong?

BR,
Peter

Re: CSS: style leaks from unrelated stylesheet

[David Grieve]

In 8u20 and before, adding a stylesheet via 
Control.getUserAgentStylesheet will simply add the user-agent stylesheet 
to the entire scene, not just the control. This has been fixed in 8u40 
where the getUserAgentStylesheet method is now public API on Region and 
the styles added will affect only the Region and its children.


Incidentally, the code you point out from the 3rd party control 
(controlsfx) was added as a work-around for a separate issue related to 
Control.getUserAgentStylesheet(). I believe the 8u40 branch of 
controlsfx has removed this work-around and is using the 
Region#getUserAgentStylesheet method.


On 10/9/14, 8:58 AM, Werner Lehmann wrote:

Turns out that the 3rd party control adds its stylesheet like this:

class SomeControlSkin...
  static {
StyleManager.getInstance().addUserAgentStylesheet(...)
  }

In this way it is not only using private API but also the stylesheet 
is not associated with only such control nodes and therefore seems to 
affect other nodes, too. Is this correct, and should the stylesheet 
rather be provided by overriding Control.getUserAgentStylesheet?


Werner

On 09.10.2014 12:00, Werner Lehmann wrote:

Then a dialog stage is displayed and its scene does not use the 3rd
party control. However, a combobox list-cell (its button cell) is still

hg: openjfx/8u-dev/rt: RT-38395: Add ability to resolve the URL given with an @import statement relative to the FX runtime

[david . grieve]

Changeset: 835a333ec7ee
Author:David Grievedavid.gri...@oracle.com
Date:  2014-09-19 08:44 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/835a333ec7ee

RT-38395: Add ability to resolve the URL given with an @import statement 
relative to the FX runtime
Reviewed-by: kcr

! modules/graphics/src/main/java/com/sun/javafx/css/StyleManager.java
! modules/graphics/src/main/java/com/sun/javafx/css/converters/URLConverter.java
! modules/graphics/src/main/java/com/sun/javafx/css/parser/CSSParser.java
+ 
tests/system/src/test/java/com/sun/javafx/css/StylesheetWithSecurityManagerTest.java
+ tests/system/src/test/resources/com/sun/javafx/css/StylesheetTest.css

hg: openjfx/8u-dev/rt: 2 new changesets

[david . grieve]

Changeset: cdc219ec5ce8
Author:David Grievedavid.gri...@oracle.com
Date:  2014-09-19 13:54 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/cdc219ec5ce8

[TEST-ONLY] RT-38687: [CSS] Using setUserAgentStylesheet() with @import syntax 
issue

! modules/graphics/src/test/java/com/sun/javafx/css/StyleManagerTest.java
+ modules/graphics/src/test/resources/com/sun/javafx/css/rt38637.css

Changeset: 8a674e9f9438
Author:David Grievedavid.gri...@oracle.com
Date:  2014-09-19 14:26 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8a674e9f9438

RT-38687: [CSS] Using setUserAgentStylesheet() with @import syntax issue

! modules/graphics/src/main/java/com/sun/javafx/css/Rule.java
! modules/graphics/src/main/java/com/sun/javafx/css/StyleManager.java

hg: openjfx/8u-dev/rt: RT-38640: [CSS, Control] Improve handling of Control.getUserAgentStylesheet()

[david . grieve]

Changeset: ea09e7b425d3
Author:David Grievedavid.gri...@oracle.com
Date:  2014-09-18 14:55 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/ea09e7b425d3

RT-38640: [CSS, Control] Improve handling of Control.getUserAgentStylesheet()
Reviewed by: kevin, jonathan

! modules/controls/src/main/java/javafx/scene/control/Control.java
! modules/controls/src/test/java/javafx/scene/control/ControlSkinTest.java
+ modules/controls/src/test/resources/javafx/scene/control/ControlSkinTest.css
! modules/graphics/src/main/java/com/sun/javafx/css/StyleManager.java
! modules/graphics/src/main/java/javafx/scene/layout/Region.java

[8u40] Post-commit review: RT-38640: Improve handling of Control.getUserAgentStylesheet()

[David Grieve]

A change was made to the Control API which removed the protected method 
getUserAgentStylesheet(). This method was  moved to Region and was made 
public:


javafx.scene.control.Control
-protected String getUserAgentStylesheet()

javafx.scene.layout.Region
+public String getUserAgentStylesheet()

Please note that while this is a binary-compatible change, it is not a 
source compatible change. Code which has overridden the protected 
getUserAgentStylesheet() method from Control will continue to run, but 
will no longer compile in 8u40. The access on the overridden method must 
be changed to public.


The benefit of this change is that CSS can be easily packaged with 
custom controls.

hg: openjfx/8u-dev/rt: 3 new changesets

[david . grieve]

Changeset: 887985e5611d
Author:David Grievedavid.gri...@oracle.com
Date:  2014-09-16 12:05 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/887985e5611d

RT-38616: ConcurrentModificationException when 
SubScene.setUserAgentStylesheet() is called

! modules/graphics/src/main/java/com/sun/javafx/css/StyleManager.java

Changeset: ce204e7db505
Author:David Grievedavid.gri...@oracle.com
Date:  2014-09-16 12:06 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/ce204e7db505

RT-38460: [CSS, Tooltip] styleable parent is null when tooltip is manually shown

! modules/controls/src/main/java/javafx/scene/control/Tooltip.java

Changeset: a61ce4ef33ae
Author:David Grievedavid.gri...@oracle.com
Date:  2014-09-16 12:06 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a61ce4ef33ae

RT-38300: [TEST ONLY] Intermittent failure in 
StylesheetTest.testRT_31316_with_complex_scenegraph

! modules/graphics/src/test/java/com/sun/javafx/css/StylesheetTest.java

[8u40] API proposal: [CSS, Control] Improve handling of Control.getUserAgentStylesheet()

[David Grieve]

Relative to https://javafx-jira.kenai.com/browse/RT-38640, I propose to 
add the following method to Region:


/**
 * An implementation may specify its own user-agent styles for this 
Region, and its children,
 * by overriding this method. These styles are used in addition to 
whatever user-agent stylesheets
 * are in use. This provides a mechanism for third parties to 
introduce styles for custom controls.

 * @return A string URL
 */
public string getUAStylesheet()

Note: an alternative is to make Control method getUserAgentStylesheet 
public and move it to Region. But I'm not sure about binary 
compatibility and, in the interest of time, I'm putting this API out 
there. The reasons for putting this API on Region is eloquently stated 
by Jonathan in the JIRA issue.

[8u40] Review Request: (RT-38395) [CSS] Add ability to resolve the URL given with an @import statement relative to the FX runtime

[David Grieve]

Kevin, Steve,

Please review
https://javafx-jira.kenai.com/browse/RT-38395
http://cr.openjdk.java.net/~dgrieve/RT-38395/webrev.00/

Thanks.

hg: openjfx/8u-dev/rt: RT-38389: SubScene.setUserAgentStylesheet() not resilient to stress

[david . grieve]

Changeset: dbc39f3566d5
Author:David Grievedavid.gri...@oracle.com
Date:  2014-09-04 16:43 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/dbc39f3566d5

RT-38389: SubScene.setUserAgentStylesheet() not resilient to stress

! apps/toys/Hello/src/main/java/hello/HelloCSS.java
! modules/graphics/src/main/java/com/sun/javafx/css/StyleManager.java

Re: TableView bug?

[David Grieve]

Possibly https://javafx-jira.kenai.com/browse/RT-38013?

On 8/29/14, 8:29 AM, Robert Fisher wrote:

Hi guys,
  
I am having some difficulties fine-tuning the style of my TableView and I'm wondering if I've found a bug.
  
It may well be related to an existing JIRA issue, so I thought I'd check here first to see if I should create a new one.
  
http://i.imgur.com/9tGc2FB.png
  
These screenshots are taken from the latest Ensemble app. Look carefully at the separator between the two column headers. Initially, and after resizing a column, you see the top version. The header width is 1 pixel too short, and the border is therefore drawn 1 pixel too far to the left.
  
After clicking on the header to change the sorting of rows, you see the bottom version. This looks better.
  
Is this a known bug?
  
Cheers,

Rob

hg: openjfx/8u-dev/rt: RT-38483: [CSS] add indefinite as a value for duration type

[david . grieve]

Changeset: 4c3674e9ab57
Author:David Grievedavid.gri...@oracle.com
Date:  2014-08-29 09:37 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/4c3674e9ab57

RT-38483: [CSS] add indefinite as a value for duration type

! modules/graphics/src/main/docs/javafx/scene/doc-files/cssref.html
! 
modules/graphics/src/main/java/com/sun/javafx/css/converters/DurationConverter.java
! modules/graphics/src/main/java/com/sun/javafx/css/parser/CSSParser.java
! modules/graphics/src/test/java/com/sun/javafx/css/parser/CSSParserTest.java

Re: Any plans to support CSS transitions?

[David Grieve]

Although the CSS features for 9 haven't been settled yet, this is high 
on my wish list.


On 8/29/14, 12:06 PM, Mike Hearn wrote:

I enjoy iterating on my UI using JFX CSS and a simple hot reload feature I
added to my app, but I still have to drop back into writing code for doing
animations. In practice this means I use fewer nice animations than I
otherwise would, as perfecting them takes longer.

CSS3 has a way to denote transitions of any styleable property. Given that
JFX already has all the infrastructure, has a similar mechanism been
considered for it?

hg: openjfx/8u-dev/rt: RT-38455: [CSS] lexer should not consume @font-face and @import as one token

[david . grieve]

Changeset: b72f6918383b
Author:David Grievedavid.gri...@oracle.com
Date:  2014-08-28 19:54 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/b72f6918383b

RT-38455: [CSS] lexer should not consume @font-face and @import as one token

! modules/graphics/src/main/java/com/sun/javafx/css/parser/CSSLexer.java
! modules/graphics/src/main/java/com/sun/javafx/css/parser/CSSParser.java

hg: openjfx/8u-dev/rt: [DOCS-ONLY] RT-38453: [CSS] errors in cssref html causing issues in various browsers

[david . grieve]

Changeset: 9ae7393e72e9
Author:David Grievedavid.gri...@oracle.com
Date:  2014-08-27 13:51 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/9ae7393e72e9

[DOCS-ONLY] RT-38453: [CSS] errors in cssref html causing issues in various 
browsers

! modules/graphics/src/main/docs/javafx/scene/doc-files/cssref.html

hg: openjfx/8u-dev/rt: RT-38391: [CSS] Add support for specifying durations

[david . grieve]

Changeset: 6efbcb758363
Author:David Grievedavid.gri...@oracle.com
Date:  2014-08-26 15:54 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/6efbcb758363

RT-38391: [CSS] Add support for specifying durations

! apps/toys/Hello/src/main/java/hello/HelloCSS.java
! modules/graphics/src/main/docs/javafx/scene/doc-files/cssref.html
! modules/graphics/src/main/java/com/sun/javafx/css/SizeUnits.java
+ 
modules/graphics/src/main/java/com/sun/javafx/css/converters/DurationConverter.java
! modules/graphics/src/main/java/com/sun/javafx/css/parser/CSSLexer.java
! modules/graphics/src/main/java/com/sun/javafx/css/parser/CSSParser.java
! modules/graphics/src/main/java/javafx/css/StyleConverter.java
! modules/graphics/src/main/java/javafx/css/StyleablePropertyFactory.java
! modules/graphics/src/test/java/com/sun/javafx/css/SizeTest.java
! modules/graphics/src/test/java/com/sun/javafx/css/parser/CSSLexerTest.java
! modules/graphics/src/test/java/javafx/css/StyleablePropertyFactoryTest.java
! 
modules/graphics/src/test/java/javafx/css/StyleablePropertyFactory_createMethod_Test.java

[8u40] Post-commit review: (RT-38391) [CSS] Add support for specifying durations

[David Grieve]

Added handling of 's' and 'ms' time units to the CSS parser.
Added public static StyleConverter?,Duration getDurationConverter() 
to javafx.css.StyleConverter
Added corresponding createStyleableDurationProperty methods to 
javafx.css.StyleablePropertyFactory.


https://javafx-jira.kenai.com/browse/RT-38391

Here is some sample code. Look for the setting of the in-line style 
-my-duration from a listener on the slider valueProperty.


import javafx.animation.Animation;
import javafx.animation.FadeTransition;
import javafx.application.Application;
import javafx.beans.binding.Bindings;
import javafx.beans.property.BooleanProperty;
import javafx.beans.property.ObjectProperty;
import javafx.beans.property.Property;
import javafx.beans.property.ReadOnlyObjectProperty;
import javafx.beans.property.SimpleBooleanProperty;
import javafx.css.CssMetaData;
import javafx.css.Styleable;
import javafx.css.StyleableProperty;
import javafx.css.StyleablePropertyFactory;
import javafx.geometry.Insets;
import javafx.geometry.Orientation;
import javafx.geometry.Pos;
import javafx.scene.Group;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.control.Label;
import javafx.scene.control.Slider;
import javafx.scene.layout.AnchorPane;
import javafx.scene.layout.BorderPane;
import javafx.scene.layout.HBox;
import javafx.scene.layout.Region;
import javafx.scene.layout.VBox;
import javafx.scene.paint.Color;
import javafx.scene.shape.Rectangle;
import javafx.scene.shape.SVGPath;
import javafx.stage.Stage;
import javafx.util.Duration;

import java.util.List;

public class Main extends Application {

private static class TestNode extends Rectangle {

public TestNode() {
super(100, 100);
}

StyleablePropertyFactoryTestNode factory = new 
StyleablePropertyFactory(Rectangle.getClassCssMetaData());
StyleablePropertyDuration myDuration = 
factory.createStyleableDurationProperty(this, myDuration, 
-my-duration, (s) - s.myDuration, Duration.millis(1000));


@Override
public ListCssMetaData? extends Styleable, ? getCssMetaData() {
return factory.getCssMetaData();
}
}

BooleanProperty fadeIn = new SimpleBooleanProperty(false);

@Override
public void start(Stage stage) {

final BorderPane pane = new BorderPane();
pane.setPadding(new Insets(10, 10, 10, 10));

Slider slider = new Slider();
slider.setPadding(new Insets(5, 5, 5, 10));
slider.setMin(500d);
slider.setMax(1500d);
slider.setBlockIncrement(50);
slider.setValue(1000d);
slider.setShowTickLabels(true);
slider.setShowTickMarks(true);
slider.setSnapToTicks(true);
slider.setOrientation(Orientation.VERTICAL);

pane.setRight(slider);

final TestNode testNode = new TestNode();
slider.valueProperty().addListener(o - 
testNode.setStyle(-my-duration:  + ((PropertyNumber) 
o).getValue().intValue() + ms;));


final Button fadeButton = new Button();
fadeButton.textProperty().bind(Bindings.when(fadeIn).then(Fade 
In).otherwise(Fade Out));

fadeButton.setOnAction(e - {
Duration duration = testNode.myDuration.getValue();
FadeTransition transition = new FadeTransition(duration, 
testNode);

transition.setFromValue(testNode.getOpacity());
transition.statusProperty().addListener(o - {
if (((ReadOnlyObjectPropertyAnimation.Status) 
o).getValue() == Animation.Status.STOPPED) {

fadeButton.setDisable(false);
} else {
fadeButton.setDisable(true);
}
});
if (fadeIn.get()) {
transition.setToValue(1.0);
transition.setByValue(5);
transition.setOnFinished(a - fadeIn.set(false));
} else {
transition.setToValue(0.1);
transition.setByValue(-5);
transition.setOnFinished(a - fadeIn.set(true));
}
transition.playFromStart();
});

VBox vbox = new VBox(5, testNode, fadeButton);
vbox.setAlignment(Pos.CENTER);
pane.setCenter(vbox);

Label label = new Label(Use slider to adjust duration of 
the\nFadeTransition, then click the button.);

pane.setTop(label);

Label status = new Label();
status.textProperty().bind(Bindings.createStringBinding(
() - testNode.myDuration.getValue().toString(),
(ObjectPropertyDuration) testNode.myDuration
));
pane.setBottom(status);

BorderPane.setAlignment(label, Pos.CENTER);
BorderPane.setAlignment(slider, Pos.CENTER);
BorderPane.setAlignment(vbox, Pos.CENTER);
BorderPane.setAlignment(status, Pos.BOTTOM_RIGHT);

Scene scene = new Scene(pane, 300, 250);
stage.setScene(scene);

Re: CSS: Use none or null?

[David Grieve]

Either one.

On 8/26/14, 4:21 PM, Tomas Mikula wrote:

Just a quick question: Which one is correct,

 -fx-fill: none;

or

 -fx-fill: null;

?

Thanks,
Tomas

[8u40] API Review Request: (RT-38192) CSS support for Region as graphicProperty on Labeled

[David Grieve]

In as much as CSS is considered public API, please review 
https://javafx-jira.kenai.com/browse/RT-38192, which allows FXML to be 
specified as the -fx-graphic property of Labeled.


Example of a Button with a graphicProperty that is specified in CSS as a 
Region shaped like an X:


@Override
public void start(Stage stage) {

Button button = new Button(Button);
Scene scene = new Scene(new StackPane(button), 200, 200);
scene.getStylesheets().add(/fxtest/test.css);
stage.setScene(scene);
stage.show();

}

/* test.css */
.button {
-fx-graphic: url(fxml:,?import 
javafx.scene.layout.Region?Region styleClass=\graphic\/);

}
.button  .graphic {
-fx-shape: M2,0 L5,4 L8,0 L10,0 L10,2 L6,5 L10,8 L10,10 L8,10 L5,6 
L2,10 L0,10 L0,8 L4,5 L0,2 L0,0 Z;

-fx-background-color: red;
-fx-min-width: 10;
-fx-min-height: 10;
}

hg: openjfx/8u-dev/rt: RT-38352: [CSS] Warning messages in media Ensemble tests

[david . grieve]

Changeset: 96b2950a91e3
Author:David Grievedavid.gri...@oracle.com
Date:  2014-08-19 12:52 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/96b2950a91e3

RT-38352: [CSS] Warning messages in media Ensemble tests

! 
apps/samples/Ensemble8/src/samples/java/ensemble/samples/media/streamingmediaplayer/PlayerPane.java
! 
apps/samples/Ensemble8/src/samples/resources/ensemble/samples/media/alphamediaplayer/AlphaMediaPlayer.css
! 
apps/samples/Ensemble8/src/samples/resources/ensemble/samples/media/overlaymediaplayer/OverlayMediaPlayer.css
! 
apps/samples/Ensemble8/src/samples/resources/ensemble/samples/media/streamingmediaplayer/StreamingMediaPlayer.css

hg: openjfx/8u-dev/rt: RT-38345: [CSS] Warning messages from CSS on touch devices

[david . grieve]

Changeset: d7373a5e9cd9
Author:David Grievedavid.gri...@oracle.com
Date:  2014-08-18 12:30 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/d7373a5e9cd9

RT-38345: [CSS] Warning messages from CSS on touch devices
Reviewed by: kevin, lisa

! modules/graphics/src/main/java/com/sun/javafx/css/parser/CSSParser.java

hg: openjfx/8u-dev/rt: 2 new changesets

[david . grieve]

Changeset: a8e87f631464
Author:David Grievedavid.gri...@oracle.com
Date:  2014-08-15 11:53 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a8e87f631464

RT-38201: [CSS] Enum values should not be treated as value references to be 
looked up

! modules/graphics/src/main/java/com/sun/javafx/css/parser/CSSParser.java

Changeset: a63ebe7c34f2
Author:David Grievedavid.gri...@oracle.com
Date:  2014-08-15 12:21 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a63ebe7c34f2

RT-38300: [TEST ONLY] Intermittent failure in 
StylesheetTest.testRT_31316_with_complex_scenegraph

! modules/graphics/src/test/java/com/sun/javafx/css/StylesheetTest.java

hg: openjfx/8u-dev/rt: Backed out changeset a63ebe7c34f2 for RT-38300 since the test still fails

[david . grieve]

Changeset: bc95b0652aca
Author:David Grievedavid.gri...@oracle.com
Date:  2014-08-15 17:42 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/bc95b0652aca

Backed out changeset a63ebe7c34f2 for RT-38300 since the test still fails

! modules/graphics/src/test/java/com/sun/javafx/css/StylesheetTest.java

hg: openjfx/8u-dev/rt: RT-38138: -fx-spacing used wrong in .menubar in modena.css

[david . grieve]

Changeset: e5dccbae218a
Author:David Grievedavid.gri...@oracle.com
Date:  2014-08-12 08:03 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e5dccbae218a

RT-38138: -fx-spacing used wrong in .menubar in modena.css
Reviewed by: kcr

! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/MenuBarSkin.java

Re: [8u40] API review: (RT-38192) CSS support for Region as graphicProperty on Labeled

[David Grieve]

That's the idea, except you wouldn't have to create and add your own Region.

On 8/7/14, 2:30 PM, Scott Palmer wrote:

So this is something like doing this:

import javafx.application.Application;
import javafx.scene.layout.Region;
import javafx.scene.layout.VBox;
import javafx.scene.control.Label;
import javafx.scene.Scene;
import javafx.stage.Stage;

public class TestSVGLabel extends Application {

public void start(Stage stage) {
Region img = new Region();
img.getStyleClass().add(graphic);
Label label = new Label(Text 123456789, img);

VBox root = new VBox();
root.getChildren().add(label);
Scene scene = new Scene(root);
scene.getStylesheets().add(svgLabel.css);
stage.setScene(scene);
stage.show();
}
}


.label  .graphic {
-fx-scale-shape: true;
-fx-position-shape: true;
-fx-min-width: 32;
-fx-min-height:32;
-fx-border-color: black;
-fx-background-color: green;
-fx-shape: M 100 100 L 300 100 L 200 300 z;
}


Note that there is a layout issue using JRE 8u20 and the above code.  It
seems the size of the Region is not considered properly and it causes the
Text to be truncated.

Scott



On Thu, Aug 7, 2014 at 4:54 AM, Tom Schindl tom.schi...@bestsolution.at
wrote:


Hi,

To me this looks like a none breaking change or do I miss something?

Still why not getting more generic and provide FXML as the graphic
syntax, the URI could be able to detect this as well, the FXMLLoader
naturally should never ever be load a controller when it is used from
inside an CSS.

Now on the syntax would it be better instead of defining svg-path to
work with protocols like browsers are doing it today (see data-urls).

We'd have then:
* file:
* http:
* ...
* data:scenegraph/svg-path;
* data:scenegraph/fxml;

Tom

On 07.08.14 00:59, David Grieve wrote:

In as much as CSS styles can be considered API, I propose the following
CSS API change for Labeled's -fx-graphic property. This will allow an
SVG path to be used as the value on Labeled's -fx-graphic property. See
https://javafx-jira.kenai.com/browse/RT-38192

Proposed CSS API for Labeled:

Allow -fx-graphic to be either a uri or an svg-path

  -fx-graphic: [ uri | svg-path ]

If -fx-graphic is a svg-path, a Region will be set as the Labeled's
graphicProperty. This Region will be given the style-class 'graphic'.

Example:

 .button { -fx-graphic: M2,0 L5,4 L8,0 L10,0 L10,2 L6,5 L10,8 L10,10
L8,10 L5,6 L2,10 L0,10 L0,8 L4,5 L0,2 L0,0 Z; }
 .button  .graphic { -fx-background-fill: red; -fx-min-width: 10;
-fx-min-height: 10; }

[8u40] Review Request: (RT-38138) -fx-spacing used wrong in .menubar in modena.css

[David Grieve]

Kevin, Steve,

Jonathan has reviewed https://javafx-jira.kenai.com/browse/RT-38138 and 
given his +1. I'm in need of a +1 from one of you before I push.



 Original Message 
Subject: 	[8u40] Review Request: (RT-38138) -fx-spacing used wrong in 
.menubar in modena.css

Date:   Tue, 05 Aug 2014 16:12:06 -0400
From:   David Grieve david.gri...@oracle.com
To: Jonathan Giles jonathan.gi...@oracle.com
CC: openjfx-dev@openjdk.java.net List openjfx-dev@openjdk.java.net



Jonathan,

Please review https://javafx-jira.kenai.com/browse/RT-38138. There are
two patches attached. The first just addresses the problem in modena.css
(and caspian.css). The second addresses the problem in MenuBarSkin and
leaves modena.css (and caspian.css) unmodified. It is the second patch
(RT-38138_01.patch) that I recommend we move forward with as it keeps
styling MenuBar and ToolBar very much the same.

After your review, I'll seek a +1 from Kevin or Steve.

[8u40] API review: (RT-38192) CSS support for Region as graphicProperty on Labeled

[David Grieve]

In as much as CSS styles can be considered API, I propose the following 
CSS API change for Labeled's -fx-graphic property. This will allow an 
SVG path to be used as the value on Labeled's -fx-graphic property. See 
https://javafx-jira.kenai.com/browse/RT-38192


Proposed CSS API for Labeled:

Allow -fx-graphic to be either a uri or an svg-path

 -fx-graphic: [ uri | svg-path ]

If -fx-graphic is a svg-path, a Region will be set as the Labeled's 
graphicProperty. This Region will be given the style-class 'graphic'.


Example:

.button { -fx-graphic: M2,0 L5,4 L8,0 L10,0 L10,2 L6,5 L10,8 
L10,10 L8,10 L5,6 L2,10 L0,10 L0,8 L4,5 L0,2 L0,0 Z; }
.button  .graphic { -fx-background-fill: red; -fx-min-width: 10; 
-fx-min-height: 10; }

hg: openjfx/8u-dev/rt: 2 new changesets

[david . grieve]

Changeset: 39c4399a3630
Author:David Grievedavid.gri...@oracle.com
Date:  2014-08-04 16:42 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/39c4399a3630

RT-38065: CSS -fx-pref-width et al do not accept infinity value

! modules/graphics/src/main/java/com/sun/javafx/css/parser/CSSParser.java

Changeset: 5c4df3d3ef9c
Author:David Grievedavid.gri...@oracle.com
Date:  2014-08-04 16:46 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/5c4df3d3ef9c

RT-37454: Node lookup with TabPane

! modules/controls/src/main/java/javafx/scene/control/Tab.java
! modules/controls/src/main/java/javafx/scene/control/TabPane.java

[8u40] Review Request: (RT-38138) -fx-spacing used wrong in .menubar in modena.css

[David Grieve]

Jonathan,

Please review https://javafx-jira.kenai.com/browse/RT-38138. There are 
two patches attached. The first just addresses the problem in modena.css 
(and caspian.css). The second addresses the problem in MenuBarSkin and 
leaves modena.css (and caspian.css) unmodified. It is the second patch 
(RT-38138_01.patch) that I recommend we move forward with as it keeps 
styling MenuBar and ToolBar very much the same.


After your review, I'll seek a +1 from Kevin or Steve.