JDK-8124093 : fx8.0-b86: CSS code for modena css rules with multiple selectors is not optimized
  • Type: Bug
  • Component: javafx
  • Sub-Component: controls
  • Affected Version: 8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2013-05-14
  • Updated: 2015-06-17
  • Resolved: 2013-06-03
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8Fixed
Related Reports
Blocks :  
JDK-8090757 - Improve JavaFX embedded performance
Description
Performance of simple Labels has been dropped significantly after switching to Modena (b86).
I wrote simple test case which draws different set of labels on every pulse.
Here are performance results on my Windows laptop:
 b85: 255 fps
 b86: 185 fps // Modena is by default
 b87: 150 fps
 b88: 125 fps
 b89: 125 fps


JPA shows that significant time increase (more than in 2 times) is observed in
  com.sun.javafx.css.StyleManager.findMatchingStyles(...).

On 5/13/13 5:22 PM, David Grieve wrote:
> The issue is that modena.css has css rules with multiple selectors and the css code is not optimized around that. 
> So this is a known issue, but there is no bug tracking it.
Comments
The fix was integrated into build 8.0-controls-scrum-603. Confirm LabelPerf was improved: 602: 174 603: 228
05-06-2013
http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/0e8bd17417d3 http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e6ec5624c645 Prior to these changes, matching a node against a selector produced a List<Rule>. Then there was a second pass on this list to get the Match data from a Rule. This second pass had to iterate over all the Selectors in the Rule. Now, matching a node against a selector produces a List<Selector> and extracting Match data from the Selector doesn't need to test whether or not the selector actually matches (since we know it does).
03-06-2013