JOGLAppletLauncher and slow repaint on Firefox/Mozilla

OpenGL Development JOGL Development
#21

I’ve also filed a bug in the bugzilla system of Mozilla/Firefox just in case… with a link to your post on opengl.org

I’ve also tried the game with FF on mac os : runs fine at full speed.

What’s strange is that it works fine on my laptop, with FF 1.5.1, and an nvidia 6200 (I’ve tweaked the nvidia options, especially the once related to vsync but couldn’t reproduce the bug on this computer).

I’m thinking of a kind of back buffer used by ff to avoid direct painting of applets into their tabbed windows (I’ve seen some old bugs saying applets were painted in the wrong tabs). In that case, the opengl rendering would have to be send to this buffer, then by FF to the screen. As I don’t know anything of FF internals, I might be absolutely wrong. And that doesn’t explain why it works on my laptop, and not on my desktop PC (NV6600).

Lilian

#22

I downloaded the FireFox sources a few days ago and looked through the Windows graphics implementation a little. However I didn’t see anything obvious in how it sets up its WNDCLASS or its HWND instances themselves that looked “strange” and that might somehow interfere with OpenGL. There is no way that a GDI-based back buffering scheme for Firefox could possibly interfere with the implementation of SwapBuffers as far as I know. I’ll wait a couple more days to see if there are any replies on opengl.org and will then probably post the same question on NVidia’s forums.

FYI, a co-worker has been looking at the Jack Flowers applet and seen quite a bit of instability (JVM crashes) even on NVidia hardware. I think he’s going to try putting -Dsun.java2d.noddraw=true in his control panel settings and test it again, but the fact that those kind of problems are showing up make me reluctant to recommend using applets as a deployment technique for JOGL apps. Let’s see how further testing looks.

#23

I’ve also found on the web a workaround to force setting a property to the applets without going through the plugin control panel… I’ll explore this path in the coming days to install -Dsun.java2d.noddraw=true (with the consent of the user, not silently).

Lilian

#24

How does this work? I would be very surprised if it were possible to do this in any way that actually had an effect. This property only has an effect if it is specified before any windows are created, so if for example it’s set in the JOGLAppletLauncher it’s already too late.

#25

here’s the workaround : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6260751

What we have to do is to check if the opengl driver is an ATI
if true, check if sun.java2d.noddraw is set to true
if false show a dialog to the user requesting his approval to install the workaround (in a user friendly way : “your 3D card may have problems with java and opengl technology, do you accept this program to install a patch to overcome these issues ?, this patch will also affect other java applets” or something better).
if the user accepts, add the property to the deployment file, and ask the user to restart his browser

This sequence must be done from the signed applet otherwise we’ll encounter security issues.

Ken, what’s your opinion on this ?

Lilian

#26

That sounds like a good workaround to me. Would you mind coding it up or should I? If you don’t have time, please file a bug with the JOGL Issue Tracker.

#27

I’ll do it in a couple of days (let’s hope nobody will complain about it : the workaround is for every applet, not just ours)

Lilian

#28

Hmm, wouldn’t this break hardware accelleration for Java2D game applets?

#29

That swapinterval bit is more like a hint. You can also call it without a param to get the currently used value… well, thats how its supposed to work, but currently only Nvidia actually supports that (havent tested it for more than a year tho… eventually it works now with ATI, too)

On the driver side you usually have 4 possible settings for vsync. Always on, on by default, off by default and always off. Only if its #2 or #3 you can change it from your application.

#30

You’re right, it would. The question is whether that would perceptibly slow things down. I have found that the WIndows GDI pipeline for Java2D is just as fast as the DirectDraw pipeline for most operations and applets I’ve seen. Try setting -Dsun.java2d.noddraw=true in your Java Control Panel and please post if you see significant slowdowns for applets you commonly run (and please post the locations of those applets as well).

#31

I’m aware of the semantics of wglSetSwapIntervalEXT. What I don’t understand is why code run inside of Mozilla/Firefox would behave differently from the exact same code running inside of IE. On my machine I can see slower performance in Mozilla 100% of the time with no changes to the driver settings. As I said it looks like wglSetSwapIntervalEXT is being silently ignored. I don’t know of any bits that can be set in the WNDCLASS or during CreateWindowEx that could affect SwapBuffers, and neither Mozilla or the Java Plug-In is using either DirectDraw or OpenGL itself. I’ve looked through the Firefox source code and didn’t find anything obviously suspicious in how it was setting up its window, and have also looked through the Java Plug-In sources and didn’t see anything that I thought could affect the behavior one way or another.

I’ll post about this on the NVidia forums this week after the holiday.

#32

waking up this topic as there are news on the mozilla bugtracking system :

I don’t know what’s this Talkback component, but may be somebody here can help, Ken ? :slight_smile:

Lilian :slight_smile:

#33

Apparently all you have to do is turn off the talkback bug reporting agent. If you are using windows you just have to find talkback.exe, run it and follow the instructions to turn it off.

#34

Incredible !

On my basic test case : from 50 to 1300 FPS !!!

!!! :smiley: :smiley: :smiley:

#35

Wow! Thanks all for tracking this down. I’ve filed and fixed Issue 263 against JOGL and documented the root cause of the slowdown in the JOGLAppletLauncher. Great detective work!!!

#36

Or you can go to Tools->Add-ons->Extensions and click the Disable button next to the Talkback entry. Or you can uninstall it altogether from the same place. For Firefox, anyway. I’ve no idea about Mozilla.

#37

Sure, if you want to do it the easy way. Certainly a little easier than doing it manually.