326381 - slow refresh rate (<30fps) for an opengl java applet (firefox and mozilla), >1000 in other browsers

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[clilian]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; fr-fr) AppleWebKit/312.8 (KHTML, like Gecko) Safari/312.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

The game linked here : http://www.javapause.com/games/jack is a java applet (using the java plug-in > 1.4) with added support for OpenGL calls (from the JOGL team).
When played, the game displays a fps counter. As vsync is programmaticaly disabled, the frame rate should be around 300 fps on any recent computer with recent opengl drivers. This is the case for every browser tested (IE 6, Opera 8.5, ...). 
On windows (at least XP) FF and mozilla aren't able to display more than 30 fps.
On some computers, the problem doesn't show (recent ogl drivers in both cases).
The problem is found with both ATI and NVIDIA cards, and can be reduced to a very long time (10 ms) spend in the glSwapBuffers() calls.

See this link for a detailed technical explanation from one of the JOGL team member : http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=9;t=000645

Could it that there's a kind of a kind of double buffering involved with ff that prevent the game running at full speed ?



Reproducible: Always

Steps to Reproduce:
1. go the the game link
2. once the starter applet is loaded, click on play to go to the opengl applet page
3. once the game is loaded (4 megs at least), click on play 
Actual Results:  
watch the fps counter in the top left corner. on IE it's above 200, on FF it's under 30


Expected Results:  
at least 200 fps on a modern pc with NVIDIA or ATI card

this problem seems to occur only on windows oses. 

It runs fine on mac os (160 fps here) with the latest ff (downloaded today)

This is a showstopper for the game and this new technology. I hope it will be addessed soon !

Comment 1

[Aras Pranckevicius]

Attachment: Slow OpenGL plugins (built+source)

The ActiveX and NPAPI plugins that just setup OpenGL, clear window and swap buffers. The drawing loop is timer invoked (max 100 FPS), I get 64FPS in IE and 30FPS in Firefox (P4 3GHz, Radeon9600Pro).

The bottleneck is the same as in our full-fledged plugin: inside wglMakeCurrent, there's a wglGetPixelFormat called that takes around 23 milliseconds. On IE, the same call takes less than 1 millisecond.

The attachment contains built plugins (IE/Firefox), sourcecode (VC7.1) and a Test.html

Comment 2

[Aras Pranckevicius]

About the above attachment: it's a minimal test case of the same problem we're experiencing in our web plugin (http://unity3d.com/unitywebplayer.html). It's much slower on Firefox than on IE (only Windows, Mac does not have this problem).

Each GL context activate takes more than 20 milliseconds, and once you have several of them (p-buffers) the thing becomes unplayable very quickly. On IE each activate takes <1ms which is ok.

Comment 3

[Aras Pranckevicius]

Also: the same test plugin is not slow in Opera (gets the same FPS as on IE)

Comment 4

[Aras Pranckevicius]

Attachment: Slow OpenGL plugins #2 (binary+source)

Updated the attachment: now includes windows batch files to install/uninstall the testcase plugins. Also fixed the Test.html page.

The response I've got so far from graphics hardware vendors is that it's "an application problem". Firefox slows down the windows built-in software OpenGL implementation as well (not only actual hardware drivers), so it must be doing something bad. E.g. something that causes a video memory -> system memory -> video memory copy on each frame (just a wild guess).

Comment 5

[Aras Pranckevicius]

Attachment: Slow OpenGL plugins #3 (binary/source)

Updated the testcase again. Now shows FPS/timing without external tools. Included full readme.txt inside with timing results on various hardware configs.

Comment 6

[Aras Pranckevicius]

After more debugging and stepping through assembly calls in IE and Firefox, I think I have found the cause of OpenGL slowdown: the Talkback component. No idea why it does that, but the test case now is this (as of version 2.0.0.1):

* Talkback enabled = OpenGL is slow.
* Talkback disabled = OpenGL is fast (i.e. same level as IE).

I have no idea what exotics does Talkback do, but I noticed that calls such as SetPixelFormat, wglMakeCurrent etc. call into fullsoft.dll at some point.

Comment 7

[Wayne Mery (:wsmwk)]

does it exhibit the same problem with breakpad using a current trunk build?

Comment 8

[Aras Pranckevicius]

No, so that's a good thing.

However, I saw one some mozilla blog saying that Firefox 3 will have half of installations using Talkback, and half of the installations using Breakpad. If that is true, that means half of the people who install Firefox 3 will be affected by this (and of course everyone who has Firefox 2 or earlier).

Comment 9

[Wayne Mery (:wsmwk)]

Ted, see comment 6

Comment 10

[(not currently active) Ted Mielczarek]

Aras: Talkback is gone on trunk Firefox builds, which are what will eventually be Firefox 3.

Wayne: I don't know anything about Talkback's operation.  It must be doing something stupid that interferes with OpenGL.

Comment 11

[Wayne Mery (:wsmwk)]

closing WFM per comment 6 - works without talkback, which will be gonzo as of FF3. Thanks Aras.