Maximized window causing slowdowns

mantesat · December 26, 2006, 8:03am

Happy holidays to all!

I’m experimenting with Java6 and the accelerated version of the GLJpanel, and I came across a strange behavior. When I maximized my app window, some times (not always), my app framerate dropped to 0.1 fps. This happened with GLJpanel, CompositeGLJpanel (Chris Campbell’s component) and GLCanvas, and I noticed it also with the CompositeGLCanvas demo posted here some days ago. The runtime args I’m using are : -Dsun.java2d.opengl=true -Dsun.java2d.noddraw=true. The noddraw parameter doesn’t seen to affect the whole thing, and if I omit the java2d.opengl parameter, everything is normal, no frame rate drops when app window is maximized, but no acceleration for GLJpanel of course. Also, at all cases, when returning to the window original size, everything is normal.

I profiled my app using yourkit, and when maximizing the app window, the profiler shows that 100% of the time is consumed to
sun.java2d.opengl.OGLRenderQueue$QueueFlusher.run() but only 40% of that time goes to the display() call. Also reported hotspots are mostly calls to com.sun.opengl.impl.GLImpl.glCallList(int), and also calls to com.sun.opengl.impl.GLImpl.glDrawElements(int, int, int, Buffer).

Any ideas? I’m using a Geforce4ti4200, with the latest drivers and with the latest jogl version/nightly build.

kbr · December 26, 2006, 9:00pm

My guess is that you’re running out of VRAM and that the back buffer for your window is getting punted to system memory, and that you’re perhaps falling back to the pbuffer -> BufferedImage -> screen rendering path in the GLJPanel. You might try -Djogl.debug.GLJPanel to see if any interesting messages get printed. My recommendation would be to buy a new graphics card.

mantesat · December 27, 2006, 8:46am

My recommendation would be to buy a new graphics card.

Well, a letter asking for a GeForce 8800 GTS has already been sent to Santa

However I don’t think that I’m falling back to the pbuffer -> BufferedImage -> screen rendering path in the GLJPanel, as you suggested Ken. That’s because I tested the same thing using a GLJpanel but without the -Dsun.java2d.opengl=true parameter, as I said at my first post. Although there was no acceleration, the app was working normally, even when the window is maximized, where the framerate is slow but significatly higher that that of the case of the accelerated GLJpanel. Also, I tried using a GLCanvas and the same thing happened some of the times the app window was maximized, there was a very very slow framerate. Without the -Dsun.java2d.opengl=true parameter, GLcanvas was working properly, even when window was maximized.

Same tests were run on a Mobility Radeon 9000 (yes, I know this is a very outdated card too :-), but at all cases (GLCanvas or GLJpanel) when the -Dsun.java2d.opengl=true parameter was used, the whole application crashed. I even tried the Gears test, to avoid using my own code in case i was doing something wrong, but it also crashed. When the -Dsun.java2d.opengl=true param was not used, everything was working normally (GLCanvas or GLJpanel, maximized app window etc).

So I believe that the problem is related to the -Dsun.java2d.opengl=true parameter, because in some way it affects not only GLJpanel, but GLCanvas too. I’m attaching the Gears test error log, in case it helps.

kbr · December 27, 2006, 8:47pm

Turning on the Java 2D / OpenGL pipeline with -Dsun.java2d.opengl=true typically requires the absolute latest drivers from the graphics card vendor (e.g. ATI or NVidia) as it pushes the OpenGL drivers to their limits and many driver bugs have been uncovered during the testing of the OpenGL backend for Java 2D. Chris Campbell would be the best one to analyze the crash you’re seeing with the ATI Mobility Radeon 9000, which is occurring upon startup of the Java 2D subsystem and is unrelated to JOGL.

You may see better behavior on your GeForce if you download and install the latest drivers from NVidia’s web site.

To be clear, the GLJPanel does have some hardware acceleration even if -Dsun.java2d.opengl=true isn’t used; that’s the case where it renders into an off-screen pbuffer, reads back into a BufferedImage, and draws that to the screen using Java 2D. It’s surprising that you’re seeing the same kind of slowdown in your app if you use a GLCanvas and also have the Java 2D / OpenGL pipeline turned on. This would indicate to me some kind of driver-level problem. While there are some interoperability issues between the GLCanvas and the Java 2D / OpenGL pipeline, there shouldn’t be anything that could cause spurious slowdowns like this. A driver upgrade may help.