JDK-8102374 : Optimize Region by using immutable State, caching on CSS level
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: controls
  • Affected Version: 7u6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2012-07-20
  • Updated: 2015-06-16
  • Resolved: 2012-09-10
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 :  
Description
There is API to describe all the styleable properties of Region. Things like background, borders etc. At the moment there are several versions of these objects at CSS, SceneGraph and Prism levels. Every time a CSS change happens we build new set of CSS objects then convert twice into SG then Prism Objects. It seems like they should all use the same set of objects and make a pile less work to do.

In addition, in order to implement the optimizations in NGRegion for render-to-texture for regions, we need a very fast way to determine if a set of backgrounds / borders have previously been drawn and cached as an image so we can reuse them. The simplest solution would be to bundle all of the backgrounds / borders into a single object on the region level which is then passed straight down to NGRegion. We need some cleverness in CSS so as to be able to very quickly determine / return a previously created list of backgrounds / borders. In addition, CSS should ensure that we have the exact same instance of Color, RadialGradient, LinearGradient, etc returned for any given set of inputs. SO for example, we could have a cache of String->Paint where derive (value, value, value) or whatnot is they key (where value is an actual numeric value). We still have to perform lookups but can then construct the resulting string and look for a previously created instance. This would allow us in Prism to do various other optimizations, as well as making subsequent hash code lookups based on a paint very quick (since the hashCode is cached).
Comments
A tweak, so close without verification.
05-11-2013

There could perhaps be more work done here in terms of caching, but we now have immutable state and there is a lot of caching going on in CSS, so I believe this is now fully resolved.
10-09-2012

Resolved as part of RT-25406, RT-22429
10-09-2012