Uncontrolled flicker

OpenGL Development JOGL Development
#1

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?

#2

I don’t think a lot of code was changed between those point releases. I seem to recall that 03 just updated some certificates. Have you tried 1.5? It kicks ass.

#3

I’ve tried downgrading back to 1.4.2_02 and still have the same issue, so I don’t think it’s the revision of Java.

I don’t think it’s jogl as the same webstart app runs fine on my other Windows machines. Please try http://home.earthlink.net/~kduling/webstart/Lesson07.html. I haven’t access to a linux box currently and I haven’t tried on my ultra5 yet.

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.

#4

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.

I think there is still some threading issues lurking somewhere…

#5

I just started out with JOGL and OpenGL today, and am suffering the same flicker problem, both with the JOGL demos and with this “single triangle” example: http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jogl;action=display;num=1058027992;start=

The offending pc is a Dell 510m laptop with Intel 82852/82855 GM/GME graphics adapter, running XP-Pro SP1 (with latest updates), and JOGL 1.1b03. I tried JDKs 1.4.2_02, 1.4.2_04, 1.4.2_05, and updated the graphics driver, none of which made any difference.

I found two things that DO stop the flickering:

  1. In the “single triangle” example, adding: glCaps.setDoubleBuffered(false);

or

  1. In Display Properties > Advanced > Troubleshoot, cranking down Acceleration by 3 notches, thus disabling DirectDraw and Direct3D acceleration.

Obviously these are not solutions but may help to shed some light.

The laptop runs Non-JOGL OpenGL apps ok, including the Java3D FlyThrough demo and games like Evolva and Clusterball.

My Win2K-Pro pc (dual head: ATI Rage Pro PCI 8MB and NVidia GeForce DDR 256) runs everything just fine (on both cards).

Any ideas, anyone?

Cheers
David

#6

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 came across a couple of games written by Kevin Glass under Xith3D. Both of these ran without problems, which gives me hope it’s some sort of setting that can be tracked down. Take a look at Martian Madness and Survivor http://grexengine.com/sections/externalgames/tech-page-Xith3D.html

#7

Caoimhin, I tried MartianMadness - no flicker. Noticed it was running an old version of JOGL so tested Gears demo with each of this years 4 JOGL releases:

jogl-1.0 No flicker :^)
jogl-1.1b01 Flicker
jogl-1.1b02 Flicker
jogl-1.1b03 Flicker

This was on my XP-Pro laptop (see spec above) with j2sdk1.4.2_05, and using the respective demos from each JOGL version.

Looks like something funny got introduced in jogl-1.1b01.

Could you test and confirm this?

Cheers
David

CPU is at 100% on all four versions.

#8

How did you determine what version of jogl Martian Madness installed?

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

#9

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.

#10

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

#11

[quote]How did you determine what version of jogl Martian Madness installed?
[/quote]
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.
[/quote]
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
[/quote]
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
[/quote]
Thanks Mac, but afraid it didn’t fix the flicker problem.

#12

Whoops, that should have been http://home.earthlink.net/~kduling/fullscreen.jar

Yes, this machine is also running Windows XP.

#13

[quote]Whoops, that should have been http://home.earthlink.net/~kduling/fullscreen.jar

Yes, this machine is also running Windows XP.
[/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…

#14

Hi All,

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?

Any other ideas?

#15

Heh heh - your race viewer is very clever ;D

Runs fine on my laptop. How about adding a “quality” control for increasing the polygon count?

Guess that would increase download time.

Where did you get jogl 1.1b04 ? Latest I can see is 1.1b03.

#16

daymark wrote:

[quote]Then it draws ok except that the spinning crate is centered over the bottom right corner of the screen…
[/quote]
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?
[/quote]
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.

#17

daymark:

[quote]Where did you get jogl 1.1b04 ? Latest I can see is 1.1b03.
[/quote]
It’s the nightly build. The breadcrumb trail is Projects > games > games-core > games-binaries
Or you can get to them from https://games-binaries.dev.java.net/build/index.html

keving:

[quote]Otherwise, they say “installing SP1 for WindowsXP should fix the problem.” (And yet, Daymark has SP1)
[/quote]
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…
[/quote]
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.

Flakey, flakey, flakey…

#18

re: Digiturf RaceViewer, Daymark wrote:[quote]Runs fine on my laptop
[/quote]
:o 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
[/quote]
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 :wink:

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?

Kevin

#19

keving wrote:

[quote]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?
[/quote]
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.

#20

I fully agree. Exclusive full-screen mode seems to be just too risky to use for a public release game.