Can wglSwapIntervalEXT silently fail?

I’m trying to track down a performance problem in an OpenGL application. Unfortunately the software stacks involved are huge – the app is a Java- and OpenGL-based game running inside a web browser. See http://www.javapause.com/games/jack .

The symptom is that the game runs slowly inside of Mozilla/Firefox, but not inside of Internet Explorer, on some Windows systems only. Of course the Java Plug-Ins and entire web browser software stacks are completely different between these two configurations. I’ve been trying to eliminate as many variables as possible. None of these stacks is using DirectDraw or Direct3D, which could cause mysterious problems. As far as I can tell no OpenGL work is being done aside from that in the Java/OpenGL binding and the OpenGL-based applet itself. On an affected system I have been able to boil down the Java applet into a tiny test case involving only a single spinning triangle. This runs at 60 FPS in Mozilla and 2000 FPS inside of IE. All of the time is going into SwapBuffers().

The behavior of the tiny test case is exactly what would happen if wglSwapIntervalEXT(0) was silently failing. In both configurations this function call returns true and wglGetSwapIntervalEXT() reports 0 for the swap interval. However when run in Mozilla the test case is clearly obeying the swap interval while when run in IE or standalone it is not. All of the OpenGL driver settings, etc. are identical in these two configurations.

The test case runs at the same frame rate both when it is embedded into the browser window (using the standard applet tag) and when the applet creates its own stand-alone top-level window and puts the OpenGL canvas into that window. That would seem to eliminate properties of the window or window class of the web browser as variables, but I’m not sure.

This behavior occurs on machines with both NVidia and ATI hardware and pretty recent drivers.

Does anybody know of things that can cause wglSwapIntervalEXT to silently fail? Window class or window style bits that can cause it to be silently defeated? Some DLL being loaded (which doesn’t in turn load DDRAW.DLL or OpenGL32.DLL; I’ve checked for that) which causes it to have no effect? I can post or try to find any additional information that might be needed to make a diagnosis.

Thanks in advance.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.