JDK-8099369 : Guimark in JavaFX runs at ~4 fps
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: fx1.2
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2009-06-22
  • Updated: 2015-06-16
  • Resolved: 2011-03-28
Related Reports
Blocks :  
JDK-8099474 - Text layout in FX is much slower than a pure Swing app
Blocks :  
JDK-8108234 - Resizing/laying out Text is way slower if the mouse cursor is over the window
Description
I promised this test for Arindam, to fully implement the Guimark http://www.craftymind.com/guimark/ testcase in JavaFX 1.2

On both Windows and OSX 10.5 on my powerbook, I score around 4-5 fps. The slow framerate comes mostly from text layout, if you go into Holder.fx and comment out the following line near the bottom

wrappingWidth: bind width-12

you will see the framerate jump to roughly 40 fps.


This test is implemented using the same constraints as the Silverlight, HTML, and Flash testcases. I didn't implement the abilty to ping the charting result of the test when it's run, since I don't know how to launch the browser with a url from javafx
Comments
For JavaFX 2.0, we are instead focusing on the "TextTest" from GUIMark2, a similar test. As of b07, performance was similarly bad (~2fps). Since then, much improvement has been made, and we currently (b20) sit at 46 fps w/ prism/d3d, and 60 fps w/ prism/j2d.
28-03-2011
Not targeting this for SoMa
07-08-2009
An update to Guimark_JavaFX1_2.fixed.zip: fps is now logged to console as well as being updated in the GUI.
16-07-2009
Attached a very slightly modified version of the test that uses a KeyFrame time of 1ms instead of 0s. This should give us more accurate FPS readings, as we have some trouble with Timelines that only have a single KeyFrame at time 0.
16-07-2009
I believe I've made some good progress in discovering why there is such a performance difference between Swing and JavaFX. See RT-5069.
02-07-2009
On Vista I also see ~4fps running with 6u14. I ran it through the NB profiler (screenshot attached) and the hotspots all come from JDK text-layout code. Not surprising, but it does beg the question of why the "Java 5 Swing" version of GUIMark runs at 30+ fps on the same machine.
29-06-2009
More info on the memory leak. Apparently the leak only occurs under Java 1.5 under Mac OS X but not 1.6. Still, 1.6 is only available on Mac for 64 bit so for now all 32 bit javafx apps on Mac will exhibit this memory leak. We confirmed this by having someone build the testcase on the Snow Leopard developer preview to test Java 1.6
25-06-2009
I built a second verison using the Label component to see if that improved things, instead it broke alot of stuff. The Label component isn't properly applying TextOverrun.CLIP, instead opting for a weird "truncate using last 1 or 2 words in text value" sort of thing. Also setting textWrap appears to do nothing so this test doesn't really flex the text layout engine since it only renders 1 line.
25-06-2009
I've found that this testcase is exposing a HUGE memory leak on Mac OS X. It appears that the gradients used in this test are being retained, although nothing in my code suggests it should. Steps to reproduce. 1. Open Holder.fx and comment out both ClipView nodes so that no text is being rendered during the test (this allows the test to render quicker) 2. Open Activity Monitor and test the app. You should see private memory climb at about 30 MB per second, and never go down. Steps to fix. 1. Inside Holder.fx, locate the 2 Rectangle nodes with LinearGradient fills, and comment out these fills. 2. Run the app, private memory should sit around 20 MBs consistently now. Since memory climbs by such a large amount per second, i'm certain that its not simply the gradient object thats being retained, but the actual internal bitmap rendered for these nodes. Testing on PC shows the memory doesn't leak, although it still eats up close to 90 MB just to run this testcase.
25-06-2009
Assign to Brent for initial evaluation.
25-06-2009
Change issue type to "Optimization" since we will use this issue to track runtime performance.
25-06-2009