GLJPanel and double buffering broken ?

OpenGL Development JOGL Development
#1

Hi!
I’m trying to use a GLJPanel to efficiently intermix Java2D content with OpenGL stuff. So far so good, but when using the GLJPanel for rendering I have horrible tearing. I was always convinced that all Swing components (wich should include the GLJPanel) are automatically double buffered, thereby avoiding tearing.

To verify that it’s not my fault that double buffering does not work I tested the standard PhotoCube demo from Chris Campbell http://weblogs.java.net/blog/2006/10/12/easy-2d3d-mixing-swing and the JOGL Swing demonstration http://download.java.net/media/jogl/builds/archive/jsr-231-webstart-current/JRefract.jnlp. Both have the same tearing problem I am experiencing.

So here’s my question: Why is double buffering not working for GLJPanel and is there a way to work around this issue ?

Thanks in advance for your efforts.

-H05h1-

#2

Tearing could be a VSync thing, rather than double buffering?

#3

Sure VSync is also an issue here, even when double buffering would be working wich I doubt with the amount of tearing I am experiencing.

Given the case that Swings double buffering is working correnctly and it is only VSync related, how do I create a GLJPanel wich uses VSync ?

#4

I would expect this to be a GLCapabilities.setVSync(bool) or similar, but there doesn’t seem to be an option I can see; you’ve probably done at least as much digging as me by now, anyway.

The examples you linked to also don’t work too well on my machine. The non-OpenGL Java2D pipeline version of the first one is ok (but presumably not terribly efficient). In both the OpenGL version of the first example and the second example, the JOGL graphics are not displayed and the Java2D graphics don’t repaint properly.

#5

Ok, now at least I got it “partially” working. The issue seems to be using “-Dsun.java2d.opengl=true”. When explicitly enabling the Java2D OpenGL pipeline you lose correct vsync support for GLCanvas and GLJPanel. It seems that Java2D is interferring in some way with JOGL thereby destroying correct vsync support.

The pragmatic solution is not to use the OpenGL pipeline of Java2D in conjunction with JOGL. This is a viable way when only using GLCanvas but unfortunately when using the GLJPanel to conveniently intermix 2D/3D you completely lose hardware acceleration without “-Dsun.java2d.opengl=true”.

So I have to choose between “horribly slow OpenGL rendering with convenient 2D/3D intermix and correct vsync” or “full hardware accelerated, vsynced OpenGL with pain in the ass Java2D intermix” … :-\

Anyone got a better alternative ?

#6

Yeah, that flag sounds about right. On a related note, for fullscreen to work properly in my app on my system (I think only with certain JREs) I need “-Dsun.java2d.noddraw=true” or similar - but it doesn’t matter to me, because I’m not trying to do anything similar to you…

Bear in mind that it’s not only vsync support you stand to loose; on my system those examples simply don’t display the JOGL content at all and the Java2D stuff is also severely borked. Assuming you expect people to use your software, you really can’t risk anything like that.

[quote]Anyone got a better alternative ?
[/quote]
XNA :wink:
(no big problems overlaying XNA & WinForms stuff IIRC)

Seriously though, for something cross-platform I don’t know. Seems like it should be feasible for something to work in the way this is intended to, but I’m afraid this just doesn’t atm.

There is an Overlay class in JOGL which IIRC is for doing Java2D Graphics stuff in a JOGL window, maybe that is useful to you.