JDK-8099474 : Text layout in FX is much slower than a pure Swing app
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: fx1.2
  • Priority: P3
  • Status: Resolved
  • Resolution: Not an Issue
  • Submitted: 2009-07-08
  • Updated: 2015-06-16
  • Resolved: 2011-05-23
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.
Other
fx2.0Resolved
Related Reports
Blocks :  
JDK-8099369 - Guimark in JavaFX runs at ~4 fps
Blocks :  
JDK-8099445 - Scene@MouseHandler.pick() is not efficient
Relates :  
JDK-8108234 - Resizing/laying out Text is way slower if the mouse cursor is over the window
Description
Umbrella issue for text layout optimization.

Investigation of RT-5001 has revealed that text-layout under JavaFX is much slower than under a pure Java app. I've attached a small suite of standalone test cases that demonstrate this. Results on my machine (Vista on a MBP) are as follows:

JTextLayout.java (pure Java/Swing): ~275fps
SwingTestLayout.fx (FX, embedded Swing: ~220fps
TextLayout.fx (pure FX using Text node): ~22fps

One cause for this has been found, RT-5069.

Some notes on running the tests:
* To get fps data for the FX version(s), you'll need:
    * to point -Djava.util.logging.config.file= to the attached logging.properties
        AND
    * a Soma build which includes the RT-4959 fix OR a Soma/Marina build w/ a diff similar to:
        http://jfxsrc.sfbay.sun.com/javafx/soma/scrum/graphics/runtime/rev/557f74ded7ac

* To get framerates > ~70 for the embedded Swing test (SwingTextLayout.fx), you'll need to increase the javafx framerate with something like:
      -Djavafx.animation.framerate=500
Comments
The reason FX 1.3 was slower than pure Swing is that it used java.awt.font.TextLayout ALL THE TIME for multi-line text If someone had added some Arabic to the Swing app it might have been much closer in performance, modulo lack of clipping smarts. Prism doesn't even have that functionality so its going to be fast for Latin text and simply won't work right for Indic/Arabic/etc In other words I don't really need an updated test case to know it'll be fine. Try running the existing test on FX 1.3 with prism and swing pipelines to get an idea of where it would be with FX 2.0. When we get TextLayout in Prism the intention is to make it do something like what Swing does. Except in the text layer and smarter too. Swing is all or nothing. We'll do it paragraph by paragraph.
29-03-2011
To truly know if this is resolved we'd need a port of the test case to FX 2.0. However, as of b14, GUIMark2.TextTest performance of both prism/d3d (43.45 fps) and prism/j2d (36.26 fps) were faster than the JavaSE/Swing version (22 fps), all under 6u23.
29-03-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
RT-5280 seems to no longer affect this test. Having the mouse in or out of the window has no effect on the framerate.
10-12-2009
See also JRE bug 6868503. Fix for it should improve performance by 30-40% (projected).
04-08-2009
In my environment i observe speed of 2-3 fps only if mouse is in the frame. And performance jumps to up to 30 fps if mouse is outside. This is because of RT-5280.
03-08-2009
Swing is using approximate metrics to layout the text. They basically estimate length of string as width_of_average_char*number_of_chars_in_string. This is what you get from FontMetrics. Note that it is not true average char metrics. This is what font creator put to the font header. In many cases this is something very different and result string width is not correct. On other hand for most popular fonts and random text Swing is getting reasonably accurate results.
01-08-2009
Something interesting from the profiling data: the text layout/measurement underlying the two versions (Swing and FX) is pretty much completely different. FX uses java.awt.font.LineBreakMeasurer, which goes through the java.awt.font.* and java.text.* packages (java.awt.font.CharArrayIterator, java.text.RuleBasedBreakIterator, java.awt.font.LintBreakMeasurer), and doesn't use java.awt.FontMetrics or sun.font.FontDesignMetrics. Swing uses, of course, the javafx.swing.text.* package, and ends up relying on java.awt.FontMetrics & sun.font.FontDesignMetrics. It (almost) completely avoids the java.text.* package.
08-07-2009