Fullscreen Headache

Hi all!

It seem whatever I do with full screen seems to be ‘write once’ - ‘test everywhere’ - ‘wait for next version’ - ‘begin again’ :frowning:

I’m really happy that jogl is so close to being final and I think you guys have done a great job bringing it this far. But does anyone have a really simple example that shows full screen working with swing.

Basically I need a JFrame in true full screen mode (not just undecorated strecteched) upon which I display a login JDialog. Then I add my canvas to the center of the frames borderLayout, and some widgets and controls around the edges.

This works fine on my NVidia but fails(black screen) most of the time on my Mattrox and ATI test machines. Btw I had this working up until 11b, but then my work around hacks for full screen stopped working (involving pauses, invalidates, packs, seperate repaints on the event thread after animator.start, etc etc)

There must be a simpler way of doing this that lets me actually get on with finnishing my game?

I know this isnt just a problem with Jogl and is as much to do with java and even the threading in the drivers, but it’s really driving me crazy.

Sadly I don’t have a small example to demonstrate this, but someone somewhere must be having the same problems??

Please help!

Regards

Peter

Take a look at the source code for the JCanyon demo, in particular the workaround in terrain.DBFlyer$Listener.init() (look for FIXME). This allows the JCanyon demo to run in full-screen mode successfully on all platforms which support it. Also are you running with -Dsun.java2d.noddraw=true on Windows? This is required for all JOGL programs due to driver-level incompatibilities between OpenGL and DirectDraw (which is used by Java2D on Windows by default).

Hi Ken,

Nice Demo btw :slight_smile: I think my problem is something to do with the bit depth. If I try to run the flyer demo in 32 bit then I see a similar result, screen goes white and stays white (b4 the loading message). It works fine in 24bit (bit slow on my mattrox, but 30fps on my nvidia)

I’ll try my app in 24 bit and see if that helps. The did auto mode selection code change again, that might have caused this? I also found the hacks you mentioned so I add those too :slight_smile:

Cheers

Peter

Hmm, now I’m getting strange exceptions with DummyGL stuff?

Peter

Windows
-Dsun.java2d.noddraw=true

Exception in thread “Thread-31” java.lang.NullPointerException
at net.java.games.jogl.impl.windows.WindowsGLContextFactory.getDummyGL(WindowsGLContextFactory.java:117)
at net.java.games.jogl.impl.windows.WindowsGLContext.choosePixelFormatAndCreateContext(WindowsGLContext.java:279)
at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.create(WindowsOnscreenGLContext.java:211)
at net.java.games.jogl.impl.windows.WindowsGLContext.makeCurrent(WindowsGLContext.java:135)
at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.makeCurrent(WindowsOnscreenGLContext.java:110)
at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:254)
at net.java.games.jogl.GLCanvas.displayImpl(GLCanvas.java:208)
at net.java.games.jogl.GLCanvas.display(GLCanvas.java:75)
at net.java.games.jogl.Animator$1.run(Animator.java:107)
at java.lang.Thread.run(Unknown Source)

What version of JOGL are you running? What do you get if you run with -Djogl.verbose on the command line? It looks to me like you’re using an old jogl.jar and maybe an old jogl.dll.

I’m using the latest version although I don’t see a version on the console with the debug set true.

I rewrote much of my startup logic today to be more similar to the Canyon demo. But I’m still getting this on the mattrox system (works ok on the nvidia):

Exception in thread “Thread-19” net.java.games.jogl.GLException: java.lang.reflect.InvocationTargetException
at net.java.games.jogl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:233)
at net.java.games.jogl.GLCanvas.display(GLCanvas.java:77)
at net.java.games.jogl.Animator$1.run(Animator.java:107)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.reflect.InvocationTargetException
at java.awt.EventQueue.invokeAndWait(EventQueue.java:851)
at net.java.games.jogl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:228)
… 3 more
Caused by: java.lang.NullPointerException
at net.java.games.jogl.impl.windows.WindowsGLContextFactory.getDummyGL(WindowsGLContextFactory.java:168)
at net.java.games.jogl.impl.windows.WindowsGLContext.choosePixelFormatAndCreateContext(WindowsGLContext.java:288)
at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.create(WindowsOnscreenGLContext.java:230)
at net.java.games.jogl.impl.windows.WindowsGLContext.makeCurrent(WindowsGLContext.java:136)
at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.makeCurrent(WindowsOnscreenGLContext.java:129)
at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:246)
at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.invokeGL(WindowsOnscreenGLContext.java:76)
at net.java.games.jogl.GLCanvas$DisplayOnEventDispatchThreadAction.run(GLCanvas.java:266)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:234)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)

version 11b11

ay check this out, sign up and complete an offer (the cheapest is blockbuster for 9.95) and receive a free psp. my friend did it, then he told me about it, and i did it, now im doing it again for my little brother. all u have to do is sign up and then once u get ur psp, u can cancel ur membership…thats what i did. trust me it works. heres the link, and u can talk to me on aim if u want my screen name is alcapone615 im online right now click this link to get started. http://www.FreePSPs.com/?r=18456954

It looks like there may be race conditions in the creation of the so-called dummy GL context which is used to get access to the WGL_ARB_pixel_format extension. I’ve seen similar problems before but was never able to track them down definitively. Are you doing heavy multithreading in your application at the time you’re creating the OpenGL canvas? Or are you trying to make two at the same time on two different threads?

Hi Ken,

I’m still playing with this issue and have ended up re-writing much of my startup code. It seems to be a threading issue as you mentioned. I’m receiving quite a bit of data from the server on a seperate thread and using serveral invokeLater calls to update various swing widgets on the screen. During all this the opengl canvas is created and added to the display…

I’m currently rethinking my startup strategy to try and simplify things. I’ll let you know if it works…

Cheers

Peter

Hi,

Well after quite a lot of work fullscreen is still not working as I would expect. It’s much more reliable since I used some of the tips from the Canyon demo, so thanks for that :slight_smile: But I’m still having some strange problems.

I have a GLCanvas in the Center of a JFrame with Swing Widgets around the outside. It seems that the tooltips no longer display properly, especially bad when overlapping onto the canvas. I’m using the following and it seemed to work fine up until now.

ToolTipManager.sharedInstance().setLightWeightPopupEnabled(false);

Also the Swing interaction seems to be much less responsive than before, ie clicks on buttons etc.

But the uggliest one is that the Webstart console is partially visable when I’m in full screen mode.

Any ideas?

Using JDK 1.4.2, Jogl 1.1b12,

Many thanks

Peter

Are you sure you’re running with the system property -Dsun.java2d.noddraw=true set? I see tooltips showing up incorrectly on my notebook in full-screen mode if that property isn’t set. However, I’m having some trouble getting the window and GLCanvas to be sized properly with this flag set due to bugs in the JDK. I’ll keep working on it and will try to post an example with this working properly later.

Hi Ken,

The tooltip problem (and web console showing through the application) seems to be webstart specific. I’m using the following to start my application:

<application-desc main-class="net.inspirational.cork.client.Cork">
    <argument>localhost</argument>
    <argument>2222</argument>
    <property name="sun.java2d.noddraw" value="true" />
</application-desc>

so the flag you mentioned should be there, I’ll do some more checking and make sure the app can see the flag.

cheers

Peter

I’m not a JNLP expert but I think you need to specify the sun.java2d.noddraw system property in the resources section instead of the application-desc section. Take a look at the jogl-demos’ JNLP files; these seem to work properly.

I just checked in three fullscreen examples to the jogl-demos tree which seem to work correctly on Windows with JDK 1.4.2, 5.0 and 6.0. I haven’t had a chance to run them on Mac OS X yet. Try running them if you have a chance and see if they help illustrate the kind of usage you’re aiming for.

Ah ha, you’re a good man! webstart is behaving normal again. Strange that I used to be able to get away with that, but anyway, I’m a happy nerd again now :slight_smile: I had a look for the demos, but I guess I need to setup cvs to be able to get to them.

So the only strangeness left is the performance on the swing, do you think I should be switching to active rendering of the swing components? It used to seem much smoother and responsive with the older jogl libs.

Maybe I can send you a link to my webstart once I polish up the GUI again and replace all the commented out code while I’ve been testing the full screen.

Cheers

Peter

Sure, please post a link to your application once it’s up. BTW, you can browse the CVS repository using the web pages at java.net and get the current copy of a given source file with just a few clicks. It’s also not that difficult to check out the sources via CVS.

Hi Ken,

Ok I found my way into the cvs stuff and got the 3 demos you mentioned running. I could have done with those about 12 months ago :wink: Seems like they follow the canyon demo ideas which is what I’ve been putting into place this last week or so. Next I will get a few of my colleagues to test out my app on some different environments and hopefully I won’t be bothering you again too soon :slight_smile:

If you email me I can send you the link since I’m still a while from publishing final code.

peter_bridge at hotmail dot com

Many thanks for your help.

Peter

Is it safe to set the property in the main class before any (J)Frame is being created and displayed?
System.setProperty(“Dsun.java2d.noddraw”, “true”)

For normal Swing properties this works (in case they’re being set before the JFrames are being created/displayed).

Is there any more detailed doc about when exactly I need to set this Jogl on Windows property? You mentioned it’s neccessary to prevent OpenGL vs Java2D (Directx accelerated) conflicts but when exactly do they occur? When there is a single Swing component next to a GLCanvas or GLJCanvas?

Thanks.

I have heard that this does not work because Web Start may have already initialized the AWT thread before that code will run. (Maybe only if you have the Java Console enabled?)

It is basically necessary to set it all the time before the JVM starts when running JOGL applications on Windows (because, as swpalmer points out, Java Web Start or another application/applet launcher might have initialized the AWT toolkit before your application starts). The interactions between DirectDraw and OpenGL may show up as bad flickering of Swing components (on my notebook), poor performance, visual artifacts, or application crashes. They also show up just when DirectDraw and OpenGL are mixed in the same application; they don’t even need to be mixed in the same top-level window.

I’ve added some documentation about this to the JOGL User’s Guide (linked from the JOGL home page). Let me know if you’d like more clarification.