GLJPanel rendering in molasses

OpenGL Development JOGL Development
#1

I have a project I am working on that uses JInternalFrames to manage several transparent JPanels over a fullscreen GLJPanel. I have no problems with the z-ordering after setting the GLJPanel opaque to false, but the performance is at a slug’s pace (about 5 fps).

To try and rule out some causes, I switched to a GLCanvas and was able to achieve my 60 fps, but of course due to the fact that it is a heavyweight component, it draws over everything.

I have ran the JRefract interoperability demo and see no difference in performance with or without the iteroperability enabled. I’ve been pulling out hair over this issue, any help would be greatly appreciated.

The same results are consistent with our entire development team. We are all developing on WIndowsXP SP2 using Netbeans 5.0. We have linked in the latest JOGL builds and are using Mustang b87.

Also, I have tried the “-Dsun.java2d.opengl=true” command line argument.

#2

Could you run with -Dsun.java2d.opengl=True -Djogl.debug.Java2D (note capitalization for both) and post the output?

What kinds of graphics cards are you using? Are you using the latest drivers from your vendor?

#3

For this laptop that I am currently on…

Operating System: Windows XP* Professional, Service Pack 2 (5.1.2600) Physical Memory: 502 MB Minimum Graphics Memory: 8 MB Maximum Graphics Memory: 128 MB Accelerator in Use: Mobile Intel(R) 915GM/GMS,910GML Express Chipset Family Video BIOS: 1224 Current Graphics Mode: 1280 by 768 True Color (60 Hz)

I have updated to the latest vendor drivers.

Here is the output from your request…


C:\Projects\Java\JGears\dist>java -Dsun.java2d.opengl=True -Djogl.debug.Java2D -Djava.library.path="C:\Program Files\Java\jogl" -jar JGears.jar
Could not enable OpenGL pipeline for default config on screen 0
JOGL/Java2D integration disabled
INIT GL IS: com.sun.opengl.impl.GLImpl
GL_VENDOR: Intel
GL_RENDERER: Intel 915GM
GL_VERSION: 1.4.0 - Build 4.14.10.4543

C:\Projects\Java\JGears\dist>

For some reason the pipeline cannot be enabled. I assume this is the problem on all our machines. I will try some of the other machines when I get to the office.

Okay, different story on office workstatioin:

Graphics processor: Quadro4 900 XGL Bus: AGP 4X Memory: 128 MB


run:
OpenGL pipeline enabled for default config on screen 0
JOGL specification version 1.0.0 
JOGL implementation version 1.0.0-pre-20060614-02:11:04
JOGL implementation vendor java.net JOGL community
OGLUtilities.UNDEFINED = 0
OGLUtilities.WINDOW = 1
OGLUtilities.PBUFFER = 2
OGLUtilities.TEXTURE = 3
OGLUtilities.FLIP_BACKBUFFER = 4
OGLUtilities.FBOBJECT = 5
Checking for Java2D/OpenGL support
Java2D support: default GraphicsConfiguration = sun.java2d.opengl.WGLGraphicsConfig
JOGL/Java2D integration enabled
Starting initialization of J2D FBO share context
Ending initialization of J2D FBO share context
BUILD SUCCESSFUL (total time: 28 seconds)

Runs VERY sluggish.

#4

I know it’s a shameless plug (I’m the author), but you could try this tool as a replacement for JInternalFrames : VLDocking.
It supports heavyweight/lightweight mixes (and is used in production in such a context).

In the demos link, there is a Java Web Start application featuring a GLCanvas working nicely among Swing JPanels.

VLDocking is dual licensed (open source/commercial).

Any feedback welcome.

Lilian :slight_smile:

#5

I would like to figure out what the problem is before I give up and try something else, besides my design requires a lot of what the Java2D pipeline has to offer.

When I get past this hurdle, I will look into your VLDocking.

#6

Java2D’s OGL pipeline does not currently work with Intel chips. This is something we hope to fix for a Mustang update release, because it should work once we add support for the WGL_ARB_make_current_read extension.

If you just run a basic Swing/2D app (like Java2Demo) with the OGL pipeline enabled, is it sluggish as well? Or is it just your JOGL app?

Which driver version and OS here? What happens if you add -Dsun.java2d.opengl.fbobject=true to your command line (in addition to the ones Ken mentioned)?

Thanks,
Chris

#7

The Java2Demo ran fine, but I did get this… (EDIT: Compared with Java2Demo running with/without the pipeline enabled: With it enabled, there is a little lag during initialization and when different tabs are selected. Once the new tab initializes it runs fine.)


C:\Documents and Settings\RodgersGB\Desktop\Java2D\Java2D>java -Dsun.java2d.open
gl=True -jar Java2Demo.jar
OpenGL pipeline enabled for default config on screen 0
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
        at javax.swing.JComponent._paintImmediately(Unknown Source)
        at javax.swing.JComponent.paintImmediately(Unknown Source)
        at javax.swing.RepaintManager.paintDirtyRegions(Unknown Source)
        at javax.swing.RepaintManager.paintDirtyRegions(Unknown Source)
        at javax.swing.RepaintManager.seqPaintDirtyRegions(Unknown Source)
        at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(Unknow
n Source)
        at java.awt.event.InvocationEvent.dispatch(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)

C:\Documents and Settings\RodgersGB\Desktop\Java2D\Java2D>

Quadro Current NVIDIA Driver Windows XP Pro SP2 ForceWare Release 80 Version: 84.26 Release Date: April 18, 2006

[quote]What happens if you add -Dsun.java2d.opengl.fbobject=true to your command line (in addition to the ones Ken mentioned)?
[/quote]
I tried this… Same results.

One more thing to note, when I put nothing for command line arguments it still runs sluggish, but with the arguments it’s basically at a stand still:

-Djogl.verbose -Dsun.java2d.opengl=True -Djogl.debug.Java2D -Dsun.java2d.opengl.fbobject=true

Thanks,
Greg

#8

With just the options -Dsun.java2d.opengl=True -Djogl.debug.Java2D (note no fbobject command line option), what exactly is sluggish on the system with the Quadro card? All rendering, or movement of JInternalFrames within the desktop pane?

What is the reported FPS of the demos.jgears.JGears demo both with and without the Java2D/OpenGL pipeline enabled, with a reasonably large window (so the case where the pipeline is disabled runs more slowly)? On my system I get something like 8 FPS with a full-screen JGears window without the Java2D/JOGL bridge and about 100+ FPS with it enabled.

#9

The frames are non-movable but translucent. With the options my mouse response has about a two second delay and Its running so slow that its hard to tell if anything is animating (I get 0.4 FPS).

Without the options the mouse has no delay but the response (drop down menus and config dialogs have delays) and its rendering at about 5 FPS.

With a GLCanvas I get 60 FPS.

I just ran your interoperability demo with and without the Java2D/JOGL bridge enabled:

Without: Normal size (34 FPS) - Fullscreen (5 FPS)
With: Normal size (23.7 FPS) - Fullscreen (7 FPS)

#10

I don’t know what’s going on here. On the systems we’ve tested on, the bridge yields enormous speedups. If SwingSet2 and the Java2Demo run at a good clip with -Dsun.java2d.opengl=True, I am surprised the JOGL bridge isn’t working better.

Do you have a machine with a GeForce FX 5000 series or newer? I have done extensive testing with the 5800 Ultra on Windows, Solaris/x86 and Linux with that card. I believe Chris and I have also tested on the ATI Radeon 9000 series cards. I wonder whether the issue is something in your hardware (which, correct me if I’m wrong, is fairly old) being used by the GLJPanel implementation that isn’t hardware accelerated in the drivers.

Without adding more timing code to the GLJPanel implementation it’s hard to know where the problem is.

#11

I tested a NVIDIA® GeForce™ 6200 and came up with these results:

Without pipeline- 14 FPS
With pipeline - 30 FPS

Is this the kind of speedups you have seen? Keep in mind, I was getting 60 FPS using a GLCanvas.

I also tested an ATI 9800 and was able to get 40 FPS. ;D

Another thing to note, with the NVIDIA® GeForce™ 6200 card I ran the interoperability test, and Without it enabled JGears showed ~31 FPS. When I tried to resized the screen it ran very sluggish. With the interoperablility enabled, it also ran at ~31 FPS, but during a mouse click + drag resize, it ran very smooth and the FPS shot up to ~150. Interesting. ???

#12

No, I was seeing full-screen frame rates of 8 FPS without the bridge and 100+ FPS with the bridge. This is with a Quadro FX Go700 (a notebook chip from about 3 years ago).

#13

Sorry for the confusion…

^^^^^^^ those results were from my app running. With a GLCanvas I was getting 60 FPS. I was asking if these results were what you would expect compared to the heavyweight component results.

The JGears window running within the JRefract Interoperability Demo yeilded these results…

The interesting thing was while I was dragging and resizing the JGears window inside the JRefract demo with the pipeline enabled, the FPS spiked up around 150 FPS, but when the resize was complete the FPS went back down to 31 FPS.

#14

When comparing the GLCanvas to the GLJPanel with the Java2D/JOGL bridge enabled, I have found that they yield similar performance. The GLJPanel case definitely chews up more of the fill rate due to how it’s implemented, but as long as that isn’t your bottleneck and all of the code and driver paths are hardware accelerated (and there are no bugs in JOGL or the bridge getting in your way), the Java2D/JOGL bridge should basically provide heavyweight performance with full lightweight compatibility.

Resizing operations cause repaints to occur which is why you’re seeing the spike in frame rate. The JRefract demo uses an FPSAnimator clamped to 60 FPS which is probably why you aren’t seeing higher frame rates, though I would expect it to be closer to 60 FPS rather than 30. Running the standalone demos.jgears.JGears demo is a better indicator of raw performance of the Java2D/JOGL bridge.

#15

Thanks for all of your help Ken. I am able to reach my goal of 60 FPS with my application (using a newer graphics card).

I did run into another problem though. I have added an inset map on a GLJPanel that is positioned on top of the main (fullscreen) GLJPanel. Without the pipeline enabled it renders correctly (but with a low frame rate). With the pipeline enabled I get 60 FPS, but the inset map does not render correctly. I have the clear color set to white with alpha set to 0.3. Here are the visual results: (the image on the left is with the pipeline enabled)

http://bellsouthpwp2.net/g/r/greg_rodgers/both.bmp

#16

Can you boil this down into a small test case so we can look at it in-house?

#17

Here is a small test case…

Visual without the pipeline enabled…

Visual with the pipeline enabled…

#18

Any feedback available?

#19

Sorry for the delay in looking at your test case. There are two problems. The first is that you’re ignoring the x and y coordinates passed to GLEventListener.reshape() in your calls to glViewport(), instead passing down (0, 0). If you change those calls to pass x and y instead (or, in fact, just take out the calls to glViewport, since JOGL does that exact call for you before calling your reshape() method) then you will see the inset map drawn roughly as you expect, only with the wrong color. The second issue is a behavioral difference in the GLJPanel when the Java2D/OpenGL pipeline and the Java2D/JOGL bridge are enabled. When they’re disabled, the GLJPanel is effectively rendered into a separate buffer and drawn over the results of the Swing and Java2D rendering. When they’re enabled, you’re drawing directly over the Java2D rendering. The only case where you need to know about this is when you’re using non-opaque GLJPanels, which your test case does. You’ll have to use another method than glClear to cause alpha-blending with the drawing which has already been done underneath your GLJPanel. In fact you should use glClear() as you’re doing now when GLJPanel.shouldPreserveColorBufferIfTranslucent() returns false. If that call returns true then you should do something like draw a translucent rectangle over the entire area of the GLJPanel instead of calling glClear(GL.GL_COLOR_BUFFER_BIT). You should still call glClear(GL.GL_DEPTH_BUFFER_BIT). You may want to look at the sources of the JGears demo in the jogl-demos tree to see how it uses the result of this call and decides which buffers to clear.