JDK-8098936 : Text node computes complete text layout, even if clipped to a much smaller size
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: fx1.2
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2009-07-02
  • Updated: 2015-06-16
  • Resolved: 2013-05-29
Related Reports
Blocks :  
JDK-8091679 - Need a device clip available to the PG node to minimise wasted work
Relates :  
JDK-8108234 - Resizing/laying out Text is way slower if the mouse cursor is over the window
Description
An interesting disovery when running the RT-5100 test case is that doubling the amount of text in Text.content will cause the pure FX version to run roughly half as fast.  Doing the same for the versions using Swing JTextArea has no effect on framerate.

So I'm lead to believe that the Text node always lays out its entire contents, even if only a small portion of it will end up on screen.  This would explain the large disparity between Swing & FX performance.

See notes in RT-5100 on how to run the test.
Comments
Fixed by RT-14356.
29-05-2013
I'd say that this bug was fixed along with RT-14356 in http://jfxsrc.us.oracle.com/javafx/8.0/scrum/graphics/rt-closed/rev/abb08b8de8fe
14-11-2012
We no longer render the text so long as there's a clip, and this is not a serious issue. Deferring.
22-07-2011
For Presidio this is not a major issue. The SGText implementation always used TextLayout which is very slow. In FX 2.0 Prism has some very simple and fast layout code, which whilst not at all useful for complex scripts works for what we presently support. Also Prism's NGText node detects the presence of a clip node and whilst it doesn't mean less layout work, it skips work at rendering time. If no clip node is present then we have no idea .. we need a device clip.
22-06-2011
The bug still exists as described as of JavaFX1.3 / JDK6u19b04. The biggest place where we see this is in the GUIMark benchmark. Outside of that benchmark, I think few if any apps rely on text layout performance. Since we're not tracking that benchmark, I've lowered the priority of this bug.
05-05-2010
Assign to Phil to evaluate for Presidio. Brent: is this still an issue that we need to address?
04-05-2010
Converted to sub-task of RT-5100
08-07-2009
(Updated original results for new test case)
08-07-2009
Updated the test project to include a different approach to determining the impact of this bug. By setting Constants.CONSTHEIGHT to true, the test will run with a constant height, and less text such that the text will always fit onscreen. The results are as follows: JTextArea: ~210 fps (Pure Swing) SwingTextLayout: ~210 fps (Swing inside FX) TextLayout ~97 fps (Pure FX) So one can conclude that roughly half of the discrepancy between Swing and FX can be attributed to something other than RT-5069.
08-07-2009
A naive hack to SGText.updateTextLayouts() got us back to ~60fps. So this bug is part, but probably not all of what's causing the disparity between Swing and FX text layout.
08-07-2009