JDK-8101902 : Reduce node count in Controls by allowing a Skin to manipulate the Control's children and layout directly
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: controls
  • Affected Version: 7u6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2012-07-16
  • Updated: 2015-06-16
  • Resolved: 2013-07-08
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
Relates :  
Relates :  
Description
The idea behind this feature is to reduce the node count, in some cases spectacularly (such as cells in a TableView) by flattening the hierarchy by one Node in some cases. Presently every Skin must return a node that represents the visuals of the control. The Control takes that node and adds it as a child. During layout, the Control then resizes the Skin. In our implementation, we had to add some trickery (make control & SkinBase have the same id, style class) so that CSS styling works transparently.

instead, we might be able to have a SkinBase in the javafx.scene.control package. This concrete implementation of Skin would have some special relationship with control, in which when you add children to SkinBase, it adds them into control, and when Control needs to be laid out, it will delegate to the SkinBase. Control would extend from Region. In this way, for some controls such as Label, we can omit the intermediate Region object in the hierarchy. This has the added benefit of allowing us to refine our CSS selector usage in Caspian such that we can do direct child selectors instead of ancestor selectors, which have very poor performance characteristics.
Comments
It was done. At least many time before the current 8.0b97. Close.
08-07-2013

All code pushed to repo and no further regressions are known.
28-07-2012

I've run some preliminary numbers using tests/performance/Controls ant run-tableview-bm. On 2.2 our composite score was 29.9fps, and on 3.0 our score is 30.42fps. I'm not sure that we're outside the margin of error yet. There are some additional fixes which are needed for this issue to be completed, such as the "managed" / layoutRoot issue. But this change in and of itself doesn't appear to be a huge win in terms of FPS. We haven't yet measured the memory usage (which should have gone down). Also, this change allows us to make further modifications such as RT-23582, which may have more impact.
23-07-2012

Initial changesets pushed to repo here: http://jfxsrc.us.oracle.com/javafx/3.0/scrum/controls/rt/rev/b4b4efb44663 http://jfxsrc.us.oracle.com/javafx/3.0/scrum/controls/rt/rev/fd3003d95715 http://jfxsrc.us.oracle.com/javafx/3.0/scrum/controls/rt-closed/rev/cb5728d053d3
17-07-2012