Sorry, I can’t reproduce this behavior. On my laptop (Windows XP, NVidia graphics hardware) without the Java2D/OpenGL pipeline JDK 5.0 runs the demos.jgears.JGears application at about 4 FPS when the demo is maximized, and JDK 6 runs it at about 6 FPS. Of course these numbers are really far off the numbers when the Java2D/OpenGL pipeline is enabled with JDK 6 (83 FPS).
Are you specifying -Dsun.java2d.noddraw=true in both cases? This is required for correctness; see the JOGL User’s Guide.
I had -Dsun.java2d.ddscale=true and -Dsun.java2d.d3d=true, and didn’t specify noddraw=true. I’ll try those. Do you think noddraw=true will improve the performance?
I’ll also try putting together my version of JCanyon into a self-contained app that can reproduce this behavior. If I do so, should I submit the bug to Sun or send it elsewhere?
These options enable more DirectDraw and Direct3D functionality in the Java2D implementation. DirectDraw/D3D and OpenGL are fundamentally incompatible at the driver level. I have seen many problems on various vendors’ cards when they are combined at all in the same application. The only way to guarantee robust behavior of JOGL on Windows platforms is to completely disable Java2D’s use of DirectDraw and D3D. The only Java2D command-line option you should specify is -Dsun.java2d.noddraw=true.
You should file a bug using the Issue Tracker on the JOGL home page. You’ll need to be an Observer of the project to do so.
I tried taking the unmodified jcanyon JOGL demo source, building it on Java 1.6 beta 2 (with JOGL beta 5) and running it, and comparing it to Java 1.5.0_07 running with -Dsun.java2d.noddraw=true (and without the opengl pipeline). This is with the AWT/heavyweight rendering. The slowdown is less obvious in heavyweight, but is still present. Once you approach the canyon, Java 1.5 beats Java 1.6 by a few fps consistently. With the extra slowdown involved in lightweight rendering, the “few fps” slowdown remains but becomes a much higher percentage. (eg. heavyweight I’d get, perhaps, 17fps->14fps, while in lightweight I’d get 8fps->5fps.)
I guess I’ll start with filing a JOGL bug, since this slowdown brings the rendering speed below the threshold at which it appears to be “animation” and turns it into a fast slideshow, and I’d really like to embed 3D in this non-opengl-mode, lightweight application.
I don’t think there’s anything that can be done in JOGL for this. While I don’t know why you’re seeing a slowdown with Mustang relative to 5.0, the framerates you’re getting for the heavyweight case clearly indicate that the lack of accelerated 3D on your ThinkPad is the issue. On modern hardware you should easily be getting >30 FPS for the heavyweight JCanyon case. The GLJPanel is going to be significantly slower in all configurations except when you can enable the Java2D/OpenGL pipeline with Mustang with -Dsun.java2d.opengl=true.
I pretty much reached the same conclusion this afternoon. I think because of the weak GPU features I’m processor-limited here in execution time.
And it appears JDK 1.6 is simply slower at the general-purpose tasks involved in rendering JCanyon. Looks like we’ll just have to see if it speeds up before release or wait for JDK 1.6.1.
The Java HotSpot client compiler has been almost completely rewritten in Mustang and uses much more general internal representation, code generation and register allocation schemes. Our internal benchmarks indicate that it beats the old client compiler on all benchmarks. That having been said, I ran the JCanyon demo side-by-side with 5.0 and do seem to see about a 10% slowdown with Mustang in some areas of the terrain. On the other hand, if you run with the server VM (java -server) there is a large speed boost in these same areas.
The direction we are moving in the Java SE 7 release is toward a tiered compilation system where the client and server compilers are merged. This will yield the startup characteristics of the client compiler and the peak performance characteristics of the server compiler. There isn’t going to be a 1.6.1 release, though there will be update releases to Mustang once it ships. It’s possible the tiered system may appear in an update although that work is targeted toward Java SE 7. I don’t anticipate an extensive amount of optimization work being done in the client compiler in the interim.
Has anyone tried JEditorPane with content type text/html with a transparent background overlaid with JLayeredPane on top of an animation? I’m doing this,
and it looks like the bottom part of the text is cut off. MacOSX, Java 6, DP5.
Yes, I know I’m challenging the technology. But it ALMOST works! So close! I want a web HUD.
John
Do you have a test case? We can check to see whether the problem happens on other platforms.
Just bring up the Java console. The problem shows up there.
Not all fonts are bad in JEditorPane, h1 an h3 work, just the ordinary fonts show similar to the Java Console. I can’t reproduce the problem on Linux
I haven’t seen any problems with the Java console on OS X. Could you please provide a self-contained test case if you’re seeing problems?
Hello,
I’m trying to run the JGears demo on a Radeon 7000 with the latest drivers and JDK 6. I have 2 monitors connected, but the window is running on only one. I’m using these arguments:
-Dsun.java2d.opengl=true
-Djogl.debug.Java2D
-Djogl.debug.GLJPanel
The debugging output follows. At the start, the frame rate is good (around 60) and it decreases as I increase the window size. But, if I make the window wider than about 1024, the gears disappear. This is less than full screen (I’m running at 1280X1024). The background still looks ok. The frame rate drops to about 10 and my mouse pointer becomes jumpy. I can make it full height no problem.
I tried -Dsun.java2d.noddraw=true as well, but it didn’t have any effect.
I can run Chris Campbell’s Bezier3DAnim demo (the one that introduced this interoperability) and the other demos that don’t use Java2d integration (i.e. Gears) at full screen without any problem.
Christopher
JOGL/Java2D integration enabled
Starting initialization of J2D FBO share context
Ending initialization of J2D FBO share context
GLJPanel.addNotify()
GLJPanel.handleReshape: (w,h) = (292,246)
Sending reshape because viewport changed
viewportX (0) ?= oglViewport.x (0)
viewportY (0) ?= oglViewport.y (24)
INIT GL IS: com.sun.opengl.impl.GLImpl
Chosen GLCapabilities: GLCapabilities [DoubleBuffered: true, Stereo: false, HardwareAccelerated: true, DepthBits: 24, StencilBits: 0, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 0, Green Accum: 0, Blue Accum: 0, Alpha Accum: 0, Multisample: false ]
glViewport(0, 24, 292, 246)
GL_VENDOR: ATI Technologies Inc.
GL_RENDERER: RADEON 7000 DDR x86/SSE2
GL_VERSION: 1.3.1072 WinXP Release
GLJPanel.handleReshape: (w,h) = (292,247)
Sending reshape because surface changed
New surface = sun.java2d.opengl.WGLSurfaceData$WGLOffScreenSurfaceData@435a3a
Sending reshape because viewport changed
viewportX (0) ?= oglViewport.x (0)
viewportY (24) ?= oglViewport.y (289)
INIT GL IS: com.sun.opengl.impl.GLImpl
Chosen GLCapabilities: GLCapabilities [DoubleBuffered: true, Stereo: false, HardwareAccelerated: true, DepthBits: 24, StencilBits: 0, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 0, Green Accum: 0, Blue Accum: 0, Alpha Accum: 0, Multisample: false ]
glViewport(0, 289, 292, 247)
GL_VENDOR: ATI Technologies Inc.
GL_RENDERER: RADEON 7000 DDR x86/SSE2
GL_VERSION: 1.3.1072 WinXP Release
GLJPanel.handleReshape: (w,h) = (961,742)
Sending reshape because surface changed
New surface = sun.java2d.opengl.WGLSurfaceData$WGLOffScreenSurfaceData@3b1f38
Sending reshape because viewport changed
viewportX (0) ?= oglViewport.x (0)
viewportY (289) ?= oglViewport.y (24)
INIT GL IS: com.sun.opengl.impl.GLImpl
Chosen GLCapabilities: GLCapabilities [DoubleBuffered: true, Stereo: false, HardwareAccelerated: true, DepthBits: 24, StencilBits: 0, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 0, Green Accum: 0, Blue Accum: 0, Alpha Accum: 0, Multisample: false ]
glViewport(0, 24, 961, 742)
GL_VENDOR: ATI Technologies Inc.
GL_RENDERER: RADEON 7000 DDR x86/SSE2
GL_VERSION: 1.3.1072 WinXP Release
GLJPanel.handleReshape: (w,h) = (1008,742)
Sending reshape because surface changed
New surface = sun.java2d.opengl.WGLSurfaceData$WGLOffScreenSurfaceData@1f01a29
INIT GL IS: com.sun.opengl.impl.GLImpl
Chosen GLCapabilities: GLCapabilities [DoubleBuffered: true, Stereo: false, HardwareAccelerated: true, DepthBits: 24, StencilBits: 0, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 0, Green Accum: 0, Blue Accum: 0, Alpha Accum: 0, Multisample: false ]
glViewport(0, 24, 1008, 742)
GL_VENDOR: ATI Technologies Inc.
GL_RENDERER: RADEON 7000 DDR x86/SSE2
GL_VERSION: 1.3.1072 WinXP Release
GLJPanel.handleReshape: (w,h) = (1011,742)
Sending reshape because surface changed
New surface = sun.java2d.opengl.WGLSurfaceData$WGLOffScreenSurfaceData@1dee400
INIT GL IS: com.sun.opengl.impl.GLImpl
Chosen GLCapabilities: GLCapabilities [DoubleBuffered: true, Stereo: false, HardwareAccelerated: true, DepthBits: 24, StencilBits: 0, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 0, Green Accum: 0, Blue Accum: 0, Alpha Accum: 0, Multisample: false ]
glViewport(0, 24, 1011, 742)
GL_VENDOR: ATI Technologies Inc.
GL_RENDERER: RADEON 7000 DDR x86/SSE2
GL_VERSION: 1.3.1072 WinXP Release
GLJPanel.handleReshape: (w,h) = (1071,742) <******* HERE IS WHERE IT STOPS DRAWING GEARS ******
Sorry for the trouble, but I doubt we’re going to be able to do anything about it. A Radeon 7000 is completely ancient at this point and I’m surprised that the Java 2D / JOGL bridge works on it at all. I don’t even think we have any of these cards in-house to test on. Have you tried running this on a more recent video card?
Hi,
Thanks for your attention to my question – your response helped me get a better graphics card for my machine. So, now I have an NVidia GEForce 7900 and I’m having a different problem.
I have installed the newest driver 93.71 and I’ve also tried 93.47 and 93.81 beta with the same result.
When I run JGears demo I get an exception in nvoglnt.dll – only if I enable -Dsun.java2d.opengl=true. I’m not getting any more debugging output than that. Obviously this is an NVidia driver file problem, but if anyone has any suggestion about what to do, I’d appreciate it. I checked the NVidia support page, and they basically insist you contact the manufacturer (Dell, in my case) which is ridiculous. I will email them too, but I bet they will claim it’s a JOGL/Java2d interoperability problem.
If I don’t enable JOGL/Java2d interoperability, it doesn’t crash, but slows to a crawl when I enlarge the window.
Oh, and I enable -Dsun.java2d.noddraw=true in all cases.
The other demos, which don’t use GLJPanel, appear to work without any problems.
Does anyone also have this problem? Any advice on how I should proceed? Right now I’m thinking I’ll just have to use a GLCanvas, but I was really wanted a lightweight component.
Christopher
I should also add I’ve tried the newest nightly build of JOGL as well as the most recent release.
Chris
I suspect this is a known and fairly recent regression in NVidia’s drivers. If you also specify -Dsun.java2d.opengl.fbobject=false does that get you past the crash?
Ken – thanks so much! That worked like a charm… full screen FPS now > 300.
Chris
Could I ask what the current status of this demo is? I’ve tried it on a handful of machines (OS X, Vista 32, Vista 64, XP 32, with nVidia and ATI video cards), but I haven’t had any luck. On the windows machines, the demo window doesn’t redraw at all. On the Mac, the demo desktop is visible, and the Hello World sub-window is visible, but none of the demos in the Action menu work.
In general, in my own code, I’ve been having the problem that whenever the Java2d OpenGL pipeline is enabled, nothing renders into any lightweight Swing components (even when not using GLJPanels). Disabling fb objects when using nvidia cards doesn’t seem to make a difference. I’ve tried a couple different JVM versions, with no luck.
Thanks,
Paul
Work is being done on the Java 2D OpenGL pipeline in the 6u10 release under development to change how it draws its pixels to the screen to use better-tested code paths through the OpenGL drivers. This should significantly increase its reliability.