[e10s] WebGL slow on e10s window

RESOLVED FIXED

Status

()

Core
Canvas: WebGL
RESOLVED FIXED
3 years ago
2 years ago

People

(Reporter: Alice0775 White, Assigned: jgilbert)

Tracking

(Depends on: 1 bug, Blocks: 3 bugs, {meta, perf})

Trunk
x86_64
Windows 7
meta, perf
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(tracking-b2g:backlog, e10s?)

Details

(URL)

(Reporter)

Description

3 years ago
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.
(Reporter)

Comment 1

3 years ago
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
(Assignee)

Comment 2

3 years ago
It's going to stay slow until we update the compositing path for e10s.
Blocks: 993639
No longer blocks: 653064
tracking-e10s: --- → ?
Keywords: perf
tracking-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.
Flags: needinfo?(jgilbert)
(Assignee)

Comment 4

3 years ago
(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.
Flags: needinfo?(jgilbert)

Updated

3 years ago
Depends on: 1066280
(Assignee)

Updated

3 years ago
No longer depends on: 1066280
(Assignee)

Updated

3 years ago
Depends on: 1077722
blocking-b2g: --- → backlog
(Reporter)

Updated

3 years ago
Blocks: 1100487

Updated

3 years ago
Duplicate of this bug: 1100487
Assignee: nobody → jgilbert
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.
tracking-e10s: + → ?
tracking-e10s: ? → m6+
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?
Flags: needinfo?(milan)
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.
Flags: needinfo?(milan)

Comment 9

2 years ago
We're doing some media related testing over the next few weeks, juan can we sneak webgl demos in with that looking for issues?
Flags: needinfo?(jbecerra)
(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]]

Comment 11

2 years ago
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.

Comment 13

2 years ago
How does one enable that?
open about:config , change layout.frame_rate to 0
blocking-b2g: backlog → ---
tracking-b2g: --- → backlog

Updated

2 years ago
Blocks: 1144120
(Assignee)

Updated

2 years ago
Depends on: 1144906
Blocks: 1063169

Updated

2 years ago
Flags: needinfo?(jbecerra)
tracking-e10s: m6+ → ---
Keywords: meta
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?
Flags: needinfo?(jgilbert)
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?
(Reporter)

Comment 17

2 years ago
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

Updated

2 years ago
tracking-e10s: --- → ?
(Assignee)

Comment 18

2 years ago
Yeah, this is done.
Slow WebGL on Linux is just a lack of hardware accel being enabled.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(jgilbert)
Resolution: --- → FIXED
(Assignee)

Comment 19

2 years ago
(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
Blocks: 1184859
You need to log in before you can comment on or make changes to this bug.