Last Comment Bug 326381 - slow refresh rate (<30fps) for an opengl java applet (firefox and mozilla), >1000 in other browsers
: slow refresh rate (<30fps) for an opengl java applet (firefox and mozilla), >...
Status: RESOLVED WORKSFORME
:
Product: Firefox
Classification: Client Software
Component: General (show other bugs)
: 2.0 Branch
: x86 Windows XP
: -- major with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
http://www.javapause.com/games/jack
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-08 00:53 PST by clilian
Modified: 2007-07-25 13:43 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Slow OpenGL plugins (built+source) (238.28 KB, application/octet-stream)
2006-07-03 07:08 PDT, Aras Pranckevicius
no flags Details
Slow OpenGL plugins #2 (binary+source) (238.87 KB, application/octet-stream)
2006-08-30 12:47 PDT, Aras Pranckevicius
no flags Details
Slow OpenGL plugins #3 (binary/source) (244.85 KB, application/octet-stream)
2006-12-21 03:09 PST, Aras Pranckevicius
no flags Details

Description clilian 2006-02-08 00:53:37 PST
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 2006-07-03 07:08:08 PDT
Created attachment 227953 [details]
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 2006-07-03 07:10:26 PDT
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 2006-07-03 07:12:45 PDT
Also: the same test plugin is not slow in Opera (gets the same FPS as on IE)
Comment 4 Aras Pranckevicius 2006-08-30 12:47:36 PDT
Created attachment 236118 [details]
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 2006-12-21 03:09:58 PST
Created attachment 249344 [details]
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 2007-01-22 05:03:04 PST
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, NI for questions) 2007-07-22 17:19:48 PDT
does it exhibit the same problem with breakpad using a current trunk build?
Comment 8 Aras Pranckevicius 2007-07-22 23:27:48 PDT
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, NI for questions) 2007-07-23 06:17:25 PDT
Ted, see comment 6
Comment 10 Ted Mielczarek [:ted.mielczarek] 2007-07-23 06:32:47 PDT
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, NI for questions) 2007-07-25 13:43:18 PDT
closing WFM per comment 6 - works without talkback, which will be gonzo as of FF3. Thanks Aras.

Note You need to log in before you can comment on or make changes to this bug.