Closed Bug 856900 Opened 7 years ago Closed 6 years ago

WebGL demos and games are slower on Firefox than on Chrome

Categories

(Core :: Canvas: WebGL, defect)

defect
Not set

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: cpeterson, Unassigned)

References

(Depends on 1 open bug, )

Details

(Whiteboard: webgl-perf)

Chrome easily hits 60 FPS on this WebGL cherry blossoms demo:

http://www.bongiovi.tw/experiments/webgl/blossom/

Firefox is slower on my MacBook Pro:

* Firefox 19 = ~30 FPS (no flickering)
* Beta 20 = ~30 FPS plus flickering landscape
* Aurora 21 = fluctuates between ~30 and ~50 FPS plus flickering landscape
* Nightly 22 = fluctuates between ~30 and ~50 FPS plus flickering landscape
Mozilla/5.0 (Windows NT 6.0; rv:25.0) Gecko/20100101 Firefox/25.0 - beta
Build ID: 20131001024718

The WebGL performance issues can be confirmed on more than one WebGL demos. For example, the following WebGL demos and games run slower on Firefox than on Chrome:
http://apps.playcanvas.com/will/doom3/gangnamstyle
http://dl.dropboxusercontent.com/u/6983010/wserv/gexp_pulpo/index.html
http://snailrace.mediacube.at/
http://yagiz.me/zombiesvscow/
http://webglsamples.googlecode.com/hg/aquarium/aquarium.html (8 FPS on Firefox vs 50 FPS on Chrome)
Summary: Chrome Experiments: WebGL cherry blossoms slower on Firefox than Chrome → WebGL demos and games are slower on Firefox than on Chrome
Confirmed comment 1 also on Ubuntu 13.04 x64, FF 25b4
OS: Mac OS X → All
Hardware: x86 → All
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:25.0) Gecko/20100101 Firefox/25.0
Build ID: 20131007213254

Confirming the behavior from comment 2 using the same links on Firefox 25 beta 6.
Also, very slow switch to fullscreen and back on http://apps.playcanvas.com/will/doom3/gangnamstyle
Also on CentOS 6.4 64 bits

status: FF 26b6 -> affected 

while work nicely in chromium!! 

Possibly it is issue of HTML5 rendering 

here is test for FF 26b6 which has less score compare to Chrome/ Chromium.

http://html5test.com/
Flags: needinfo?
This is well-known. The main fix for this will come when we turn on OGL acceleration for linux.
A temporary fix is bug 942302, where we should be able to use pixmaps to get better compositing perf.
Flags: needinfo?
Depends on: 942302
Whiteboard: webgl-perf
Duplicate of this bug: 958530
Here is another example, I get an FPS drop of 51 frames per second on my html5 video player going from chrome to FF when viewing a 720p video (chrome had an average of 59 frames per second, firefox had an average of 8 frames per second):

http://dl.dropboxusercontent.com/u/20328726/hbmp/test.html (not 720p but a performance drop is still visible)
I see 5-10x perf differences vs Chrome on Ubuntu:

Ubuntu 12.04 + i5 laptop + nvidia 750M w/proprietary drivers + Firefox 29 gets 38 fps with the classic WebGL Aquarium demo. Chrome 34.0.1847.132 gets 180 fps (no vsync), 5x difference. For http://threejs.org/examples/#webgl_marchingcubes the numbers are 27 fps for Firefox and 275 fps for Chrome (10x difference).
(In reply to Patrick Martin from comment #8)
> Here is another example, I get an FPS drop of 51 frames per second on my
> html5 video player going from chrome to FF when viewing a 720p video (chrome
> had an average of 59 frames per second, firefox had an average of 8 frames
> per second):
> 
> http://dl.dropboxusercontent.com/u/20328726/hbmp/test.html (not 720p but a
> performance drop is still visible)

This is bug 814524.
(In reply to Erno Kuusela from comment #9)
> I see 5-10x perf differences vs Chrome on Ubuntu:
> 
> Ubuntu 12.04 + i5 laptop + nvidia 750M w/proprietary drivers + Firefox 29
> gets 38 fps with the classic WebGL Aquarium demo. Chrome 34.0.1847.132 gets
> 180 fps (no vsync), 5x difference. For
> http://threejs.org/examples/#webgl_marchingcubes the numbers are 27 fps for
> Firefox and 275 fps for Chrome (10x difference).

This is bug 594876 or bug 942302.
(In reply to Jeff Gilbert [:jgilbert] from comment #12)
> (In reply to Erno Kuusela from comment #9)
> > I see 5-10x perf differences vs Chrome on Ubuntu:
> > 
> > Ubuntu 12.04 + i5 laptop + nvidia 750M w/proprietary drivers + Firefox 29
> > gets 38 fps with the classic WebGL Aquarium demo. Chrome 34.0.1847.132 gets
> > 180 fps (no vsync), 5x difference. For
> > http://threejs.org/examples/#webgl_marchingcubes the numbers are 27 fps for
> > Firefox and 275 fps for Chrome (10x difference).
> 
> This is bug 594876 or bug 942302.

Rather, both those bugs are really bug 1010527.
In my case (slow three.js demo, Windows 8.1 x64) setting gfx.direct2d.force-enabled=true change fps from 12 to 58.
same bug for me, most basic demos are slow in firefox (32). Moreover the framerate depends on the size of the canvas. 

I fixed the framerate problem by setting :
- webgl.force-enabled = true
- webgl.prefer-native-gl = true

now i have same framerates in firefox and chrome
Unfortunately I don't think this bug has gained any traction since it was filed over a year ago. I think what makes the most sense at this point is that we start breaking this out somehow as there are probably multiple bugs at play here. At the very least something needs to be done to make this actionable otherwise there's no point in having a bug on file.

Chris, how do you want to handle this?
Comment 1 morphed my bug report about the Cherry Blossoms Chrome Experiment into a catch-all bug for all WebGL performance problems. Since this bug itself is not actionable, I agree that it makes sense to close it.
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(cpeterson)
Resolution: --- → INCOMPLETE
Thank you Chris.

To anyone else following along here, please file separate bugs for specific demos which are considerably slower in Firefox than Chrome. If you can, please provide links to the demos, information about your system configuration (hardware, drivers, etc), and specific benchmark numbers. Also, be sure to include webgl-perf in the whiteboard field.

This will allow us to isolate, investigate, and prioritize the issues separately, and will give us a better idea of the breadth of the issue as a whole.

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