JDK-8093587 : SwingBalls demo is too slow on Mac
  • Type: Bug
  • Component: javafx
  • Sub-Component: swing
  • Affected Version: 8
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • Submitted: 2013-04-26
  • Updated: 2015-06-12
  • Resolved: 2014-07-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 9
9Resolved
Related Reports
Relates :  
JDK-8088790 - JTextArea in SwingNode isn't usable
Description
rt-closed/toys/SwingBalls demo shows only 5 (swing) fps on Mac against 28 fps on Windows.
Comments
Fixed in JDK: https://bugs.openjdk.java.net/browse/JDK-8041129. So, there's no need to set -Dswing.volatileImageBufferEnabled=false any longer.
10-07-2014
The native function which does the pixel transfer is this: OGLBlitLoops_SurfaceToSwBlit(...) in src/share/native/sun/java2d/opengl/OGLBlitLoops.c. And the bottleneck is this: // we must read one scanline at a time because there is no way // to read starting at the top-left corner of the source region while (height > 0) { j2d_glPixelStorei(GL_PACK_SKIP_ROWS, dsty); j2d_glReadPixels(srcx, srcy, width, 1, pf.format, pf.type, pDst); srcy--; dsty++; height--; } It reads the image by scanlines, from the bottom to the top. The reason is that the OGL coordinate system has the opposite (comparing the j2d) direction of the Y axis. So, the image is stored upside down. For the sake of an experiment I tried to read the image at once. This indeed boosts the performance by ~100 times, thus making it comparable to the volatile-off mode (see the previous post). However, the image should be turned over. I did that on the java side (with the array of pixels) and this downgraded the performance by ~10 times. So as the result, this approach is roughly 10 times faster, but is still 10 times slower than the volatile-off mode...
16-01-2014
Looks like the problem is in the exchange b/w a volatile image and a buffered image. After Swing draws the content into a volatile double buffer, it then copies the image to the Graphics which is tight to the root BufferedImage (the buffer used by JLightweightFrame to share the pixels with FX). I did some measuring, and what I saw is that the draw method took in average 1-3 ms in case of volatile off (when a BufferedImage is used as a double buffer), whereas it took in average 300-400 ms in case of volatile on. (I played with the SwingSet2_in_SwingNode demo).
19-12-2013
Setting -Dswing.volatileImageBufferEnabled=false raises the performance to 38 (swing) fps.
26-04-2013