1517916 - Skeletal Animation: Slow (FPS) on Firefox compare to Chrome

Status: NEW

(Core :: JavaScript Engine: JIT, defect, P2)

Description

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:64.0) Gecko/20100101 Firefox/64.0

Steps to reproduce:

http://aws-website-webassemblyskeletalanimation-ffaza.s3-website-us-east-1.amazonaws.com/

Just wanted to make aware the Firefox performance team for a large performance deference between Chrome and Firefox in this particular website. The number of runners is kept to the default of 8 and the performance is shown below:

JavaScript: Firefox (10fps) vs Chrome (45fps)
WebAssembly: Firefox (25fps) vs Chrome (45fps)

Note: I have WebRender enabled and hardware acceleration on linux stable version of firefox (enabled using environment variable)

Source code of demo:
https://github.com/sessamekesh/wasm-3d-animation-demo 


Actual results:

While there is a performance difference between JavaScript and WebAssembly (that was the purpose of this whole demo) the performance for both is nearly half of the of Chrome 


Expected results:

Performance should be on par or higher than Chrome and the a performance difference between JavaScript and WebAssembly

Comment 1

[John]

(In reply to John from comment #0)
> User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6)
> AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.1.2 Safari/605.1.15
> 
> Steps to reproduce:
> 
> http://aws-website-webassemblyskeletalanimation-ffaza.s3-website-us-east-1.
> amazonaws.com/
> 
> Just wanted to make aware the Firefox performance team for a large
> performance deference between Chrome and Firefox in this particular website.
> The number of runners is kept to the default of 8 and the performance is
> shown below:
> 
> JavaScript: Firefox (10fps) vs Chrome (45fps)
> WebAssembly: Firefox (25fps) vs Chrome (45fps)
> 
> Note: I have WebRender enabled and hardware acceleration on linux stable
> version of firefox (enabled using environment variable)
> 
> Source code of demo:
> https://github.com/sessamekesh/wasm-3d-animation-demo 
> 
> 
> Actual results:
> 
> While there is a performance difference between JavaScript and WebAssembly
> (that was the purpose of this whole demo) the performance for both is nearly
> half of the of Chrome 
> 
> 
> Expected results:
> 
> Performance should be on par or higher than Chrome and the a performance
> difference between JavaScript and WebAssembly

User Agent is wrong, it was changed by an extension

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:64.0) Gecko/20100101 Firefox/64.0

Comment 2

[John]

Setup used (to have something as a reference point):
- Computer: Dell XPS 9530
- External Screen: Dell 25'' (2560 x 1440)

Additional info:
- Turning off acceleration (and hence WebRender) doesn't have any difference in the number of fps
- Making the window take half the screen size (JavaScript 15fps and WebAssembly 40fps)

Comment 3

[Luke Wagner [:luke]]

For the performance with "WebAssembly" selected on the top-right: I think unfortunately we are being hurt here by our default Linux graphics doing expensive extra copies of the GL canvas; when I profile with perf.html, I see a lot of time under mozilla::gl::GLContext::raw_fReadPixels. On my OSX laptop, where we avoid this copy, I see a solid 60FPS and the reported per-frame times look the same as Chrome's.

However, I do see a perf difference when "JavaScript" is selected, even on OSX, and perf.html shows most of the self time is indeed JS, so that might be worth looking into.

Comment 4

[John]

(In reply to Luke Wagner [:luke] from comment #3)

For the performance with "WebAssembly" selected on the top-right: I think unfortunately we are being hurt here by our default Linux graphics doing expensive extra copies of the GL canvas; when I profile with perf.html, I see a lot of time under mozilla::gl::GLContext::raw_fReadPixels. On my OSX laptop, where we avoid this copy, I see a solid 60FPS and the reported per-frame times look the same as Chrome's.

However, I do see a perf difference when "JavaScript" is selected, even on OSX, and perf.html shows most of the self time is indeed JS, so that might be worth looking into.

I could also report the performance on Windows if it would help. Also if you need me to run any benchmarks or provide any logs just tell me what I need to do

Comment 5

[Luke Wagner [:luke]]

(In reply to John from comment #4)
Yes, thanks, it would be interesting to hear how both JavaScript and WebAssembly compare on Windows.

Comment 6

[John]

(In reply to Luke Wagner [:luke] from comment #5)

(In reply to John from comment #4)
Yes, thanks, it would be interesting to hear how both JavaScript and WebAssembly compare on Windows.

Performance on Windows 10:

Edge

JS: 13fps
Wasm: 60fps

Chrome

JS: 50-60fps
Wasm: 60fps

Firefox (Direct3D 11 compositor)

JS: 30fps
Wasm: 60fps

Note: Unfortunately couldn't test WebRender as I don't know how to force activate on windows (it was blocked because I am running a laptop and it needed a setup with a computer without battery)

Performance on Ubuntu 18.10 (updated)

Chrome

JS: 45fps
Wasm: 45fps

Firefox

JS: 17fps
Wasm: 26fps

Comment 7

[Nicolas B. Pierron [:nbp]]

Kannan, would it be possible to have a chrome profile and compare it against the JS profile to know if there is any JS function worth looking into, unless we have some obvious repeated-bailout?

Comment 8

[Daniel Holbert [:dholbert]]

FWIW, I can reproduce on Linux (Ubuntu 18.10). Note that you have to click the graph in the top left a few times to get it to show FPS rather than other metrics.

I see ~5-10 fps in Firefox Nightly, vs. ~25 FPS in Chrome. I tried enabling WebRender, too, and it didn't help.

Comment 9

[Luke Wagner [:luke]]

Linux perf numbers are not especially useful so long as the GLContext::raw_fReadPixels() (which I understand to be some sort of extra GL readback that is avoided on other platforms) dominates which is, iiuc, a well-known and long-standing issue on FF Linux. The main interesting thing I think is the variation of JS perf on Windows.

Comment 10

[Daniel Holbert [:dholbert]]

Yeah -- here's a profile from my Linux Nightly, with window maximized:
https://perfht.ml/2QPTw5h
We're spending quite a while in painting, which probably corresponds to what Luke is talking about.

If I reduce the size of my browser window to make it pretty tiny (to reduce the amount of stuff we have to paint), my FPS gets a lot better (goes up to ~20 FPS, while Chrome goes up to ~35 FPS for the same change), and I get this profile, which seems more focused on the JS performance: https://perfht.ml/2VVzWIE

Comment 11

[Markus Stange [:mstange]]

On macOS there doesn't seem to be much overhead from the use of WebGL itself, and I see almost 100% of the time spent in JavaScript during the animation, on the JS testcase. Almost 40% of that seems to be inside typed array creation, and I filed bug 1520286 about that.

Comment 12

[Kannan Vijayan [:djvj]]

I simply don't have time to look into this. Thanks :dholbert for taking a look. Clearing needinfo.

Comment 13

[Mayank Bansal]

With 64 runners:

Javascript: https://share.firefox.dev/47aqqX7
WASM: https://share.firefox.dev/3XavoyA