1191962 - Poor performance on hardware acceleration test versus Chrome

Status: NEW

(Core :: Graphics, defect, P3)

Description

[aaron.hastings11]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150630154324

Steps to reproduce:

Use the Hardware Acceleration Stress Test from the Mozilla Developer Network. Run test.

Link:
https://developer.mozilla.org/media/uploads/demos/p/a/paulrouget/8bfba7f0b6c62d877a2b82dd5e10931e/hacksmozillaorg-achi_1334270447_demo_package/HWACCEL/


Actual results:

Very poor performance on a new MacBook Pro (2.7GHz Intel Core i5, Intel Iris Graphics 6100) - 20-24FPS maximum.

The same page on Google Chrome is visibly (and extraordinarily) faster, hitting the "60FPS+" mark with ease.


Expected results:

If Firefox is leveraging hardware acceleration on this platform, as a user, I expect it to match Chrome's performance, or at least get somewhere within a reasonable margin.

Disabling hardware acceleration doesn't seem to make much of a difference, dropping just a few FPS down to about 16FPS.

Comment 1

[aaron.hastings11]

To add: Currently Nightly build [42.0a1 (2015-08-06)] fairs marginally better, with about 35-37FPS average.

Comment 2

[kalviskajaks]

i5-4440 CPU @ 3.10GHz and GTX 780
Had to edit the page to remove the fps cap. After that i got 
64 fps in Firefox
229 fps in Chrome
and 319 fps in IE.

Firefox seems to be 4 to 5 times slower than the competition.

Comment 3

[u279076]

Aaron, do you have a current test that reproduces this? Seems like the link you provided no longer has the test.

Comment 4

[ovidiu boca[:Ovidiu]]

Tested on MacBook Pro 2GHz Intel Core i7,  OS X 10.9 with Firefox Nightly 47.0a1(2016-02-24), for the test I used this link: https://greensock.com/js/speed.html

Test results:

Chrome:                     90-100 fps
Nightly with e10s enabled:  30-40 fps
Nightly with e10s disabled: 30-40 fps

Anthony, this tests are enough for this issue, if not please tell me how can I help.

Kalviskajaks did you do the test with the link provided by reporter?

Comment 5

[kalviskajaks]

Yes i used the test in the link from the reporter, although it looks like the original test isn't there anymore, unfortunately i have long ago deleted the copy of the test i downloaded.

Comment 6

[aaron.hastings11]

Apologies Anthony, I've been extremely busy recently. I should responded to this sooner.

I have used the test Ovidiu linked to. I set it to jQuery (300 dots). Please note that I am now using Ubuntu 15.10 (x86_64) Linux. Here are my results:

== Firefox 44.0.2 ==
Min: 9 fps
Max: 12 fps

== Firefox Nightly 47.0a1 (2016-02-24) ==
Min: 13 fps
Max: 16fps

== Google Chrome 48.0.2564.116 ==
Min: 49 fps
Max: 57 fps

Summary: modest improvements (~30%) with the latest build of Nightly compared to Firefox stable. However, Google Chrome is still performing over 500% faster in this particular test.

Comment 7

[ovidiu boca[:Ovidiu]]

Tested on MacBook Pro 2GHz Intel Core i7,  OS X 10.9 with Firefox Nightly 47.0a1(2016-02-24)

Steps to reproduce:

1. Go to  https://greensock.com/js/speed.html
2. Set it to jQuery (300 dots) and start the test
3. See the fps 
4. Compare the results with Chrome


Actual results: The test result on Nightly is worse compared to chrome.

Expected results: The test result on Nightly should be similar with the test result on chrome.

Comment 8

[u279076]

(In reply to aaron.hastings11 from comment #6)
> Apologies Anthony, I've been extremely busy recently. I should responded to
> this sooner.
> 
> I have used the test Ovidiu linked to. I set it to jQuery (300 dots). Please
> note that I am now using Ubuntu 15.10 (x86_64) Linux. Here are my results:
> 
> == Firefox 44.0.2 ==
> Min: 9 fps
> Max: 12 fps
> 
> == Firefox Nightly 47.0a1 (2016-02-24) ==
> Min: 13 fps
> Max: 16fps
> 
> == Google Chrome 48.0.2564.116 ==
> Min: 49 fps
> Max: 57 fps
> 
> Summary: modest improvements (~30%) with the latest build of Nightly
> compared to Firefox stable.

I suspect this could be due to e10s on Nightly. Would you mind retesting Nightly with e10s disabled to see if there's a difference and how it compares to release? At least then we know you're testing under similar conditions. Assuming so, the next step we'll need you to follow is to see if this was every competitive to Chrome by testing previous Firefox releases.

Thanks

Comment 9

[aaron.hastings11]

Apologies, I should have been more clear about the fact I have e10s *enabled* in *Firefox stable*.

Anyway, sure thing. Here you go:

== Firefox 45.0 - e10s enabled ==
Min: 8 fps
Max: 15 fps

== Firefox 45.0 - e10s disabled ==
Min: 16 fps
Max: 38 fps

== Firefox Nightly 47.0a1 (2016-03-04) - e10s enabled ==
Min: 14 fps
Max: 18fps

== Firefox Nightly 47.0a1 (2016-03-04) - e10s disabled ==
Min: 22 fps
Max: 40 fps


Woah! I did not expect that. Disabling e10s on either Firefox stable or Nightly made a massive difference - in a good way!

Comment 10

[Matt Woodrow (:mattwoodrow)]

This page is creating a huge number of tiny layers, one for each animated dot (because it adjusts top/left and we create an AGR for that).

Some of these get optimized to ImageLayers, others do not. The ones that don't are what hurt us a lot.

Since we're using SingleTiledContentClient, we have to allocate a new shmem for every resize (which is every frame).

This adds up to a huge amount of time allocating and clearing Shmems.

We also spend a lot of time in layer transactions, serializing all the layer properties.

Getting all the images into ImageLayers would likely help a lot for this specific page.

As a more general fix, I think we should avoid layerizing for top/left if the content is smaller than a specific threshold.

One problem with these AGRs is that it forces all content above it to be in a separate layer, so a single animated left value splits one layer into three. This is mainly because we think these layers might move relative to each other in the compositor, but we don't support animating top/left there.

Requiring the VisualOverflowRect() of a frame to be 60x60 (on a retina display) before allowing it to be layerized for top/left doubles the frame rate of this testcase.

We replace all the layer allocation overhead with some extra painting cost instead.

The remaining slowness is because the webpage seems to be reading properties a lot, including 'left'. These all require at least a style flush, and in the case of left, a full layout flush (reflow). This sucks quite a lot, but I'm not sure if we can avoid it easily.

Any thoughts on this Markus?

Comment 11

[Markus Stange [:mstange]]

(In reply to Matt Woodrow (:mattwoodrow) from comment #10)
> Getting all the images into ImageLayers would likely help a lot for this
> specific page.

Yeah I think that's what we want.

> As a more general fix, I think we should avoid layerizing for top/left if
> the content is smaller than a specific threshold.

This is a good idea, but it'll prevent us from using ImageLayers in this testcase, won't it?

> One problem with these AGRs is that it forces all content above it to be in
> a separate layer, so a single animated left value splits one layer into
> three. This is mainly because we think these layers might move relative to
> each other in the compositor

No, my thinking was that I didn't want to have invalidations when they move relative to each other on the main thread. Mostly prompted by bug 922766 comment 3.

> The remaining slowness is because the webpage seems to be reading properties
> a lot, including 'left'. These all require at least a style flush, and in
> the case of left, a full layout flush (reflow). This sucks quite a lot, but
> I'm not sure if we can avoid it easily.

I'd expect all browsers to have problems with this part.