Build Identifier: https://hg.mozilla.org/mozilla-central/rev/366b5c0c02d3 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140622030203 WebGL is slow on e10s window Steps To Reproduce: 1. Open https://webglsamples.googlecode.com/hg/aquarium/aquarium.html --- observe fps 2. Restart browser 3. Open e10s window 4. Open https://webglsamples.googlecode.com/hg/aquarium/aquarium.html --- observe fps Actual Results fps on e10s window is much less than the fps on normal window. fps of e10s window is 30-50% of normal window.

Graphics -------- Adapter Description: ATI Radeon HD 4300/4500 Series Adapter Drivers: aticfx64 aticfx64 aticfx32 aticfx32 atiumd64 atidxx64 atiumdag atidxx32 atiumdva atiumd6a atitmm64 Adapter RAM: 512 ClearType Parameters: Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 50 Device ID: 0x954f Direct2D Enabled: true DirectWrite Enabled: true (6.2.9200.16492) Driver Date: 4-29-2013 Driver Version: 8.970.100.1100 GPU #2 Active: false GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC) Vendor ID: 0x1002 WebGL Renderer: Google Inc. -- ANGLE (ATI Radeon HD 4300/4500 Series Direct3D9Ex vs_3_0 ps_3_0) windowLayerManagerRemote: true AzureCanvasBackend: direct2d AzureContentBackend: direct2d AzureFallbackCanvasBackend: cairo AzureSkiaAccelerated: 0

It's going to stay slow until we update the compositing path for e10s.

Hi Jeff, do we have a bug open on updating the compositing path for e10s from comment 2? I just tried on a Macbook Pro, 15" w/ Retina. I can get 60 FPS w/ and w/o e10s until 4000 fish. Then I get about 40 FPS with e10s and 60 FPS without e10s.

(In reply to Mason Chang [:mchang] from comment #3) > Hi Jeff, do we have a bug open on updating the compositing path for e10s > from comment 2? I just tried on a Macbook Pro, 15" w/ Retina. I can get 60 > FPS w/ and w/o e10s until 4000 fish. Then I get about 40 FPS with e10s and > 60 FPS without e10s. Bug 1066280 is half the problem. We don't have a bug yet for the second half.

Nom'ing for retriage. This bug was e10s-tracking=+ but Luke says this bug is critical for Mozilla's games initiative and should block Aurora.

Milan, sounds like we need to be able to share textures across processes for this to be acceptably fast. Do you have a plan for that?

As in the firm schedule? No. WebGL resources are on GDC and once that clears out, we should be able to spend more time on other things. May still happen along the way, but it isn't quite the first in line.

We're doing some media related testing over the next few weeks, juan can we sneak webgl demos in with that looking for issues?

(In reply to Alice0775 White from comment #0) > > fps on e10s window is much less than the fps on normal window. > fps of e10s window is 30-50% of normal window. Just to confirm these numbers, we recently updated a talos tool to compare e10s vs non e10s results (compare.py at the talos repo). It indicates that the talos glterrain test (in ASAP mode = vsync off) is about 3x slower in e10s compared to than non e10s results. Sample: > $ python compare.py --compare-e10s --rev 0189941a3fd5 --pgo --verbose --branch Firefox --platform Win7 --master-revision 0189941a3fd5 --print-graph-url > > test Master gmean stddev points change gmean stddev points graph-url > Win7: > ... > :( glterrain 4.9 +/- 2% (4#) [+280.5%] 18.8 +/- 1% (4#) http://graphs.mozilla.org/graph.html#tests=[[325,1,47],[325,1,25]]

What is the ASAP mode exactly? It disables vsync on requestAnimationFrame, or?

Yes, it disregards vsync intervals and tries to render the frames as soon as possible, while not blocking on swapinterval where applicable.

How does one enable that?

open about:config , change layout.frame_rate to 0

I encountered a similar behavior on Firefox 42.0a1 (2015-07-16) e10s window, using Ubuntu 14.04 32-bit with the following WebGL animation: http://madebyevan.com/webgl-water/ The browser response time was delayed with about 4 seconds in a e10s window compared with a non-e10s window where the interaction commands were applied almost instantly. Testing with the WebGL sample from Description, I did not notice a difference between e10s and non-e10s windows. Based on the above mentioned should I track this issue for all platforms or should I file a new one?

I believe this bug should be marked fixed - at least for Windows. I tested on both the URL from comment 0 and the talos WebGL test, and on both of those e10s WebGL performance seem to be pretty much the same as non-e10s - on Windows. Jeff, should this be marked FIXED? How much is bug 1077722 blocking this? As for comment 15, I believe there's another bug open for WebGL perf on Linux, But I don't recall its number right now. Jeff?

I can confirm that the problem is no longer existing. Performance progression range: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c7720cbbe62e&tochange=c4d1692d88ee Fixed by: c4d1692d88ee Jeff Gilbert — Bug 1144906 - Add accel E10S backend for WebGL compositing. - r=jrmuizel,mattwoodrow,nical,sotaro

Yeah, this is done. Slow WebGL on Linux is just a lack of hardware accel being enabled.

(In reply to Vasilica Mihasca, QA [:vasilica_mihasca] from comment #15) > I encountered a similar behavior on Firefox 42.0a1 (2015-07-16) e10s window, > using Ubuntu 14.04 32-bit with the following WebGL animation: > http://madebyevan.com/webgl-water/ > The browser response time was delayed with about 4 seconds in a e10s window > compared with a non-e10s window where the interaction commands were applied > almost instantly. > > Testing with the WebGL sample from Description, I did not notice a > difference between e10s and non-e10s windows. > > Based on the above mentioned should I track this issue for all platforms or > should I file a new one? Please file a new one, thanks!

(In reply to Jeff Gilbert [:jgilbert] from comment #19) > Please file a new one, thanks! Filed Bug 1184859