makeCurrent problem

[DavidYazel]

Question 1:

Is it legal to call canvas.display()  (where canvas is a GLDrawable) from any thread and at any time if all my GL calls are done inside the display(GLDrawable) callback?  In other words if JOGL is in the middle of repainting for some reason outside my control, like handling an OS requested repaint, does it properly block the request to display until it can?

Question 2:

Every time I move a window over my frame which contains the GLDrawable I get the following:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23

net.java.games.jogl.GLException: Error making context current         at net.java.games.jogl.impl.windows.WindowsGLContext.makeCurrent(Windows GLContext.java:125)         at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.makeCurrent (WindowsOnscreenGLContext.java:110)         at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:162)         at net.java.games.jogl.GLCanvas.displayImpl(GLCanvas.java:196)         at net.java.games.jogl.GLCanvas.display(GLCanvas.java:91)         at net.java.games.jogl.GLCanvas.paint(GLCanvas.java:102)         at sun.awt.RepaintArea.paint(RepaintArea.java:177)         at sun.awt.windows.WComponentPeer.handleEvent(WComponentPeer.java:260)         at java.awt.Component.dispatchEventImpl(Component.java:3678)         at java.awt.Component.dispatchEvent(Component.java:3477)         at java.awt.EventQueue.dispatchEvent(EventQueue.java:456)         at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchTh read.java:201)         at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThre ad.java:151)         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)         at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)

There seems to be nothing I can do to stop it.

Question 3:

If I draw a frame and then the window needs to be redrawn due to a OS level repaint why does the window go white in the occluded areas and never refreshed?

This is true even if I am sitting in a loop in my main thread doing a canvas.display() over and over.

[Ken Russell]

Question 1:

Is it legal to call canvas.display()  (where canvas is a GLDrawable) from any thread and at any time if all my GL calls are done inside the display(GLDrawable) callback?  In other words if JOGL is in the middle of repainting for some reason outside my control, like handling an OS requested repaint, does it properly block the request to display until it can?

Yes, the proper synchronization is done internally to handle this. Note that currently the implementation can't handle calling the display() method of a drawable while you're inside the display() method of another (or the same one). Unfortunately this restriction isn't documented but fixing it is high on the list of things to do.

Question 2:

Every time I move a window over my frame which contains the GLDrawable I get the following:

(snip)

I haven't seen a problem like this. Look at any of the jogl-demos demonstrations; they don't seem to exhibit this problem. If you can boil it down to a small test case and it looks like valid code then please file a bug.

Question 3:

If I draw a frame and then the window needs to be redrawn due to a OS level repaint why does the window go white in the occluded areas and never refreshed?

This is true even if I am sitting in a loop in my main thread doing a canvas.display() over and over.

Haven't seen this problem. Many of the demos use either the Animator or setRenderingThread() / setNoAutoRedrawMode() directly to get around multithreaded repainting issues, but unless you're doing something complicated with pbuffers (which some of the demos, like HWShadowmapsSimple and ProceduralTexturePhysics do) then having a repaint request come in every now and then shouldn't matter.

[gregorypierce]

I have seen this happen on WindowsXP, particularly when the screen is occluded by other Java components such as Swing controls (see Wurm Client).

Games published by our own members! Check 'em out!

[swpalmer]

Maybe you should disable Swing's use of DirectX so OpenGL can play nice with the graphics card.

[gregorypierce]

I will resist the urge to get on my soap box and ask 'who in the heck though it was a good idea to put a platform specific API into a multiplatform system.'

I any event I will take a look at which options are necessary to turn off DirectX rendering in Swing.

[Ken Russell]

Specify -Dsun.java2d.noddraw=true on the command line.

[swpalmer]

BTW, I discussed this a bit with some guys from the Java2D team (Chet) and they mentioned that the OpenGL acceleration for Java2D that is meant primarily for Linux will likely happen on Windows as well.. then having OpenGL as the main path to accelerated rendering will make it play nice with JOGL etc..  It is also encouraging because this may mean that OpenGL bindings will become part of the core.

They will keep DirectX acceleration simply because of the quality issues with OpenGL support in many graphics drivers. DX is often better supported.

I think this is targeted for 1.5.

[Archimedes]

(..) then having OpenGL as the main path to accelerated rendering will make it play nice with JOGL etc..  It is also encouraging because this may mean that OpenGL bindings will become part of the core. (..)

You made my day! :-)
Very good "probably" news. :-)