2 weeks ago, this WinXP machine was running jogl apps just fine. Now, not even the Gears demo works properly.

I'm seeing this on only one machine so I'm sure this is something local, but I don't know how to track it down. The effect I'm seeing is as if jogl apps are not using a backbuffer. I'm seeing tearing and transparency when I shouldn't.

Neither new code I've written nor my older (untouched) jars from the nehe tutorials are displaying properly. The only thing I can think of that changed on this system was that I upgraded from Java 1.4.2_02 to 1.4.2_04.

Conversely, all C/C++ OpenGL demos are working fine.

I'll try downgrading Java to see if that changes anything, but can anyone think of anything else to look at?

I haven't had any hardware changes. I haven't even installed any other graphics applications or video drivers.

This sort of unknown problem bothers me because it appears to be something completely unrelated to my app, yet it is significantly impacting my app's performance. Were this a situation where I was deploying commercial software and a customer was running into this issue, I'd like to know how to troubleshoot it.

In the end, I'm sure an OS reload will solve it, but that's like using a shotgun to kill a mosquito.

This sounds very similar to a problem that I am having on linux. I seem to lose the back buffer when I resize the GLCanvas, and sometimes it comes back when I resize it again. Mine was triggered when I upgraded my video card to a Nvidia Quadro card, and has persisted between Java 1.4.2_03, 1.4.2_04, 1.5.0 b2.

It's good to know I'm not alone in this. I'll have to try playing with the glCaps on Tuesday when I get back into the office.

Another item of interest is that now when I run the Gears demo, my CPU is pegged. It didn't used to be. Before it used to take about 3% CPU, which really makes me think it's some sort of vsync issue.

Earlier today I also lowered my HW accel down and saw the issue went away. And I confirmed that other OpenGL applications still run just fine.

None of the NeHe tutorials now work on this system. I've also tried them in fullscreen mode and simply got a gray colored screen. And I still can't think of any software that I've installed/removed in the last couple of weeks. But on June 11th, everything was fine. Very very strange.

The system that is failing is a Dell desktop p4 2.2Ghz system with an ATI Rage 128 Pro Ultra with 64 megs.

I just put the lastest jogl on to this machine, my Gateway centrino with an ATI Radeon Mobility 9600 and windowed apps are running fine. But fullscreen apps are just gray screens that don't respond to keystrokes.

I found the older jogl binaries under the Documents and Files link on the jogl project page. I'm downloading each now to try each one against the binary I'm having trouble with. You might like to try this one version that does fullscreen and see if you have the same grey problem I do. http://www.earthlink.net/~kduling/fullscreen.jar

I've narrowed down the fullscreen problem that I'm having on this machine (Gateway centrino, ATI Radeon Mobility 9600) to it having been introduced in jogl 1.1b01,.

I'm finding that 1.0 is completely reliable for switching into fullscreen mode, but 1.1b01 and 1.1b02 are flakey, succeeding about 50% of the time. 1.1b03 is guaranteed to fail each time I attempt to run the app in fullscreen mode. Once I've failed with 1.1b03, I can't get the system properly entering fullscreen again without downgrading to 1.0.

Don't know if this helps at all since I havent had the problem you described but try specifying -Dsun.java2d.noddraw=true to the jvm on startup. That disables java2d's use of directdraw on windows machines, it is after all a well known fact that OpenGL and DirectX don't play nice together.//Mac

Just saw it was smaller than recent releases and had a Sep-03 datestamp.

Quote

I just put the lastest jogl on to this machine, my Gateway centrino with an ATI Radeon Mobility 9600 and windowed apps are running fine. But fullscreen apps are just gray screens that don't respond to keystrokes.

Which OS on this machine? If its not XPP I'm wondering if this might be the common denominator regarding the original flicker problem...

Quote

I found the older jogl binaries under the Documents and Files link on the jogl project page. I'm downloading each now to try each one against the binary I'm having trouble with. You might like to try this one version that does fullscreen and see if you have the same grey problem I do. http://www.earthlink.net/~kduling/fullscreen.jar

Afraid the link is broken so couldn't try this.

Quote

Don't know if this helps at all since I havent had the problem you described but try specifying -Dsun.java2d.noddraw=true to the jvm on startup. That disables java2d's use of directdraw on windows machines, it is after all a well known fact that OpenGL and DirectX don't play nice together.//Mac

Running fullscreen.jar under jogl-1.0 in non-fullscreen mode works on my mischeivous laptop. But running in fullscreen mode produces a grey screen as you described - unless I add Mac's suggestion of -Dsun.java2d.noddraw=true. Then it draws ok except that the spinning crate is centered over the bottom right corner of the screen...

The new Digiturf horse-racing viewer went live on the web a week ago (http://www.digiturf.com) and while it works perfectly for the vast majority of our players, a handful have complained about problems similar to what you have described. I did witness the effect first-hand once - jogl appeared to be drawing directly to the front buffer - it ran very slowly (1-2 frames a second) and you could see individual triangles being drawn until the whole frame had been rendered and then the process would start all over again for the next frame. Unfortunately I don't have access to this machine anymore.

Those with this problem all seem to be running on machines with the Intel 82845 chipset. This may be similar to Daymark's 82852/82855?

We have not been able to establish a pattern in the versions of Windows or J2RE they are using, mainly because they don't tell us these things...

AFAIK, some of the affected players have loaded the latest Intel drivers with no effect.

We are using JOGL version 1.1.0-b04.

For reliability, the viewer does not run in true full-screen mode, rather it sets windows decorations off and resizes itself to the current display dimensions.

We have until now not been able to obtain a machine with this hardware to test with, but Intel have loaned us a motherboard with this chipset - we will set this up on Monday - and a colleague will bring in a PC from home that has this hardware.

I have seen -Dsun.java2d.noddraw=true recommended in this and other threads but have been unable to try it - it would be difficult to talk an angry, non-PC literate user in another country into setting this as a Windows environment variable in the hope that it might work for him, and I am reluctant to set this globaly for all users in the JNLP.

Though not directly related to this problem, I have read http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4713003 and I gather that the noddraw setting is more of a work-around than a fix. This bug report also refers to bug 4812026 specifically in connection with the Intel 82845 chipset, but I get "This bug is not available" when I try to view it. Otherwise, they say "installing SP1 for WindowsXP should fix the problem." (And yet, Daymark has SP1)

Are there any risks in setting sun.java2d.noddraw to true for everyone? Could it break things for those players for which the viewer is currently working? Will it slow down Swing?

Does anyone know any more about bug 4812026? Is there maybe a fix for this in a later JRE release? Is this specifically a WindowsXP problem?

Then it draws ok except that the spinning crate is centered over the bottom right corner of the screen...

That could be because you are using a layoutmanager that places it there? I would recommend using a borderlayout on your container and explicitly specifying Borderlayout.CENTER when adding the GLCanvas

keving wrote:

Quote

Are there any risks in setting sun.java2d.noddraw to true for everyone? Could it break things for those players for which the viewer is currently working? Will it slow down Swing?

Personally I would recommend against setting it as an environment variable since that would affect all java programs and may as you say slow down other gui apps. If you are distributing your app to a lot of computer illiterate people then I'm guessing you are using some sort of launcher or at least a shell script for starting it up? If that is the case, adding the -D... option on the command line to the VM for your app only should be easy. If you are using webstart on the other hand I'm not very familiar with that but I can't imagine that it's not possible to specify vm start parameters to it?Oh! He he maybe you were asking if it could break anything when applied to YOUR app? Im not that fast a thinker. Well, I would think it's perfectly safe. And if you are not using swing a lot (as in just for menus and such) you should not see any performance loss I guess. If you are running the app fullscreen you should most definetly disable ddraw because as I said earlier OGL and DX don't like each other.

Otherwise, they say "installing SP1 for WindowsXP should fix the problem." (And yet, Daymark has SP1)

I've also got Windows XP SP1 on this laptop.

daymark:

Quote

Running fullscreen.jar under jogl-1.0 in non-fullscreen mode works on my mischeivous laptop. But running in fullscreen mode produces a grey screen as you described - unless I add Mac's suggestion of -Dsun.java2d.noddraw=true. Then it draws ok except that the spinning crate is centered over the bottom right corner of the screen...

It shouldn't be in the bottom right. It should be centered on the screen just as it is centered in the window in non-fullscreen.

Is this the same 82852/82855 laptop that you are having the flickering problem with the JOGL Demos? Are you running the viewer with DirectDraw and Direct3D acceleration turned off?

Have you tried the Demos with jogl 1.1b04? If you still have the Race Viewer installed in Webstart, you can pull this version of jogl from your Webstart cache. Look for the files RMjogl.jar and RMjogl_lib.jar. Rename RMjogl.jar to jogl.jar, and extract jogl.dll from RMjogl_lib.jar.

Quote

How about adding a "quality" control for increasing the polygon count...Guess that would increase download time

Not only that, we had to be sure of a decent frame rate on most average machines. This version peaks at about 120 000 triangles rendered per frame if the maximum of 14 horses, the starting gate and the main grandstand are all visible. There are some enhancements planned - watch this space

Regarding full-screen mode, why don't you do what I did and just resize your main window to the display dimensions and turn off decorations? I went this route because I read about and experienced myself the general flakiness and unpredictability of exclusive full-screen mode with jogl. Maybe just simulating full sceen mode will be sufficient for your app?

Regarding full-screen mode, why don't you do what I did and just resize your main window to the display dimensions and turn off decorations? I went this route because I read about and experienced myself the general flakiness and unpredictability of exclusive full-screen mode with jogl. Maybe just simulating full sceen mode will be sufficient for your app?

One could certainly do that, but that method has drawbacks. It might be sufficient, it might not. The biggest is that you don't know what resolution the user is running their system at. My desktop is at 1600x1200. Performance varies with screen resolution size. By just maximizing a 640x480 windowed application your framerate could drop from 60 to ...oh, about 4.

If the user is getting poor performance from the application, the only way for them to change resolution is for them to change it overall for the system. That's not acceptable. Fullscreen exclusive modes have been in use on computers and game platforms for years.

Every commercial game I've played in the last 5 years has had a section for screen resolution in the game configuration screens.

The bottom line is that it shouldn't be flakey. It should either work, or not work. But this situation where it works on this card but not on that card is exceedingly frustrating.

keving wrote:Is this the same 82852/82855 laptop that you are having the flickering problem with the JOGL Demos? Are you running the viewer with DirectDraw and Direct3D acceleration turned off?

Yep, same laptop, full acceleration. Gears demo flickers under all version of jogl after 1.0, but your Race Viewer runs fine.

Quote

keving wrote:Have you tried the Demos with jogl 1.1b04? If you still have the Race Viewer installed in Webstart, you can pull this version of jogl from your Webstart cache. Look for the files RMjogl.jar and RMjogl_lib.jar. Rename RMjogl.jar to jogl.jar, and extract jogl.dll from RMjogl_lib.jar.

Couldn't see the RM* jars, but downloaded current jogl nightly build and Gears demo still flickers. Must say deploying a nightly build with a production app sounds pretty scary.

Quote

keving wrote:Maybe just simulating full sceen mode will be sufficient for your app?

Fullscreen is not a big issue for me. My app is only at the idea stage. I'm learning OGL and evaluating Java bindings, trying to find a stable foundation on which to build. Maybe write a facade layer to decouple the app from the bindings and reduce risk of being locked in to something flakey. Maybe even write a minimalist binding with just the features I need, as and when I need them. Would regain some control.

The current version of the race viewer is a port from GL4Java and I used the Gears demo source code as a starting point - so I don't think there's anything significantly different in the race viewer wrt setting up the JFrame, animator and GLCanvas etc. - and I don't think there's really much else to consider? I'll look at the Gears demo source again - maybe I'll find some clues as to why the demos flicker on some machines, and not the race viewer, and vice versa.

I have not yet been able to test noddraw=true on a machine that displays this problem. I might have to email a JNLP file with this setting to one of the users to test.

daymark:

Quote

Must say deploying a nightly build with a production app sounds pretty scary.

Is this really a "Nightly Build" anymore? I'm using the version from https://games-binaries.dev.java.net/build/index.html - under nightly builds and dated 14 May 2004. that one has since been replaced by a new build dated 17 May. No new builds since than. The 14 May build was the version I used throughout development and testing and at the time of deployment I decided that the risk in going back to b03 or forward to the 17 May build was greater than just staying with what I knew was working for me.

In any event, the flickering problem exists even with the latest builds.

The funny thing is by default it chooses the default generic microsoft driver (even if I request hardware accelerated) and I get flicker. If I try to specify what I want in the pixel format, particularly depthbits then it chooss the ATI driver but I get a completely white screen. This raises several questions - why would the generic microsoft driver flicker ? It supports double buffer and I have tried specifing double buffer or not, and why when it chooses the ATI driver do I not see anything at all ?

I have several other openGL applications and they choose and run the ati driver fine. If I force the microsoft generic driver on it also works fine for other apps.

Any ideas, as I am keen to use jogl but can't until this basic problem is solved ?

The funny thing is by default it chooses the default generic microsoft driver (even if I request hardware accelerated) and I get flicker. If I try to specify what I want in the pixel format, particularly depthbits then it chooss the ATI driver but I get a completely white screen. This raises several questions - why would the generic microsoft driver flicker ? It supports double buffer and I have tried specifing double buffer or not, and why when it chooses the ATI driver do I not see anything at all ?

I have several other openGL applications and they choose and run the ati driver fine. If I force the microsoft generic driver on it also works fine for other apps.

Any ideas, as I am keen to use jogl but can't until this basic problem is solved ?

I hadn't noticed the driver was changing (didn't know it could!) until I read this, so I did some more testing of my laptop running Gears. There is a definite correspondance between MS driver and flicker:

I have seen this too with one of the Race Viewer users who has the flickering problem on Intel 82845 graphics.

Would you mind running the Race Viewer again (i.e with no flicker) and check what driver it's using in your case - details are written to the Java console on start-up. Remember that the Race Viewer is using the 14 May build of JOGL 1.1b04.

Just curious: You mention GL version 4.14.10.3701? Is this maybe a typo? According to http://www.intel.com/support/graphics/sb/CS-009479.htm#845 the leading "4" indicates a Windows 95/98/NT driver, but you have Windows XP? Possibly, the OpenGL version numbers aren't necessarily always the same as the Driver version numbers?

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org