1220429 - Large cross-browser rendering performance difference ~30 fps vs ~150 fps

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect, P3)

Description

[andrew.luetgers]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36

Steps to reproduce:

go to http://jsfiddle.net/zme8f7k8/5/



Actual results:

frame rate hovers around 15 - 20 fps


Expected results:

nearly a year ago this was much faster. I have filed the same issue with with chromium https://code.google.com/p/chromium/issues/detail?id=550044

I do get good performance in Safari around 210 fps. 
Performance in Firefox does go to 60 fps if I set cell visibility: hidden; I would expect to see that or much better performance with visibility.

Comment 1

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

For Firefox 25, 31, 38 and 41, I always get frame rates between 20-30. So maybe it was a change in React which decreased performance. Can you please tell us in which Firefox version it runs faster? You can find old Firefox versions for trying at https://ftp.mozilla.org/pub/firefox/releases/ . Thank you.

Comment 2

[andrew.luetgers]

this should have nothing to do with react as the main loop is using pure DOM api, react just does the initial render. Sorry for the complexity of the example. Over at chromium they seem to be making some headway. Also not that this behavior is the same with divs vs table. Here is an example of that http://jsfiddle.net/6f1m815c/

Comment 3

[andrew.luetgers]

I will try some older versions of Firefox tonight. As I recall there was never a performance problem with this when I initially coded it up many months ago. In coming back to it the perf issue appeared with no changes to the jsfiddle.

Comment 4

[andrew.luetgers]

Could not recreate in any older versions either. Looks Like the version I should have referenced is http://jsfiddle.net/zme8f7k8/4/
which has most of the updates off-screen. Sorry this is probably not a regression as the performance in this example is much better. However there is a large discrepancy between the original example and safari but that is a different concern than a regression. Sorry for the confusion.

Comment 5

[ovidiu boca[:Ovidiu]]

Hi, Andrew

I have tested this link: http://jsfiddle.net/6f1m815c/ with FF Nightly 45.0a1 (2015-11-08) on MAC OS X 10.10. I also use chrome to compare the performance and the result is the same on both browsers. 
If you want please download the latest nightly from here: https://nightly.mozilla.org/ and try to see if you have problems.

Comment 6

[ovidiu boca[:Ovidiu]]

Hi Andrew, 

I have tested again this problem and I can reproduce with FF Nightly 45.0a1 (2015-11-16) on MAC OS X 10.10. I have tested also on Firefox 40 frame rate hovers around 30 - 40 fps, I have tested on Firefox 42 frame rate hovers around 19 - 35 fps.
I am not sore what is the right number of fps.

Steps to reproduce:

go to http://jsfiddle.net/zme8f7k8/5/

Actual results from Nightly:

frame rate hovers around 15 - 20 fps

Please tell me if you have updates about this problem.

Comment 7

[Till Schneidereit [:till]]

Ovidiu, can you please add a comment explaining why you're moving a bug to a component? If you did some investigation that shows this is related to something in the JS engine, then the results of that investigation and STR would be very useful. If not, then please at least explain why you think it's a reasonable guess that it's related to the JS engine.

Comment 8

[ovidiu boca[:Ovidiu]]

Hi, 
I tested this and I can reproduced so the next step is to moving to a component. I didn't change the status to new because I was expecting the response from the reporter. After I will receive the response I will look after duplicates, if no duplicates the status will be new.

Comment 9

[Till Schneidereit [:till]]

Well, but why *this* component? What in your testing made you assume this is related to the JS engine as opposed to, say, the style, layout, or rendering system?

Comment 10

[ovidiu boca[:Ovidiu]]

Hi, 
I was looking after other bugs with same problem. If you think the component is not the proper one please tell me.

Comment 11

[Till Schneidereit [:till]]

(In reply to ovidiu boca from comment #10)
> I was looking after other bugs with same problem.

What same problem? Performance regressions with very similar symptoms, i.e. profiler results that show more time is spent in the same subsystem?

> If you think the component is not the proper one please tell me.

I don't know if it is the right component or not. That's exactly my point: if you move a bug to a component, please explain why you do so. Just moving the bug without any explanation at all causes one of two things: either it's simply ignored, worse IMO, someone spends time trying to understand why you moved it there, repeating something you already did. If, OTOH, you don't really have a strong reason for thinking that the component is right, then please don't move it there. It causes additional work for other people.

Comment 12

[Ryan VanderMeulen [:RyanVM]]

FWIW, Edge gets 160+ fps on my Win10 system while Fx/Chrome are closer to 20. Hard to say where this bug should live without some profiling or a clear regression range, though.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

Also FWIW, it runs ~20fps going back as Firefox 4 in my local testing. If it's true that it ran faster a year ago, that seems to support the thought that something changed outside of the browser itself.

Comment 14

[Boris Zbarsky [:bzbarsky]]

What this bug needs is:

1)  A clear description of what problem it's trying to cover.  There are now multiple testcase URLs in this bug, and it's not clear which of them are relevant and which are not.

2)  Once we have an answer to #1, a profile.  But we need an answer to #1 first.  Once that's sorted out, please put the relevant URL in the URL field for the bug.

Comment 15

[andrew.luetgers]

Per comment 4 I mistakenly reported this as a regression. It is not a regression. The issue should probably be closed as such. I apologize, complexities of isolating performance variances based on what is or is not on-screen lead to the error of thinking that it was a regression.

However my concern remains that Safari and apparently Edge perform dramatically better than Firefox and Chrome but that is definitely not a bug so much as a matter of improving performance.

Since I incorrectly reported this what follows may all be moot but personally I would love to see if there are yet dramatic performance gains to be made based on the cross-browser differences described above.

The correct url is http://jsfiddle.net/zme8f7k8/5
use the above path to audit the code use the below following for profiling
http://jsfiddle.net/zme8f7k8/5/embedded/result/

It is important to isolate variances in rendering performance based on what is or is not on screen by making sure the entire table is displayed.

Both the observed behavior of this code and remedial profiling of it strongly indicate that the rendering subsystems are of concern not the js engine. In profiling you can see that the flame chart is dominated by large blue blocks of graphics. In particular a simple test is to modify the css to hide the table. The frame rate goes up dramatically.

Comment 16

[Ryan VanderMeulen [:RyanVM]]

FWIW, I just collected a profile of both testcases and both show Graphics being about 80% of the time spent, with the rest being mostly GC/JIT.

Comment 17

[Nicolas Silva [:nical]]

I profiled and saw a lot of nsDisplayList/FrameLayerBuilder stuff (more so than actual painting) with some hash table manipulation under it. The profiler's ui is crashing the browser a lot for me today so I'll let someone else investigate (and focus on what's causing the crash that gets in my way perhaps!).

Comment 18

[Nicolas Silva [:nical]]

Ok, I managed to get a profile and stare at it for a moment without crashing :)

http://people.mozilla.org/~bgirard/cleopatra/#report=7c9dd5e54087c4718692c4e5b9ac56cb2efe67bb&invertCallback=true&selection=%22(total)%22,45

So we spend about 10% of the cpu time performing some hash table manipulations in layout. I don't see this nearly as much usually.
In another profile, FrameLayerBuilder::ComputeGeometryChangeForItem scored noticeably high as well. I don't have display list dumps enabled but I bet we have an unusually large displaylist, and some operations that aren't usually hot get scaled in a bad way.

Comment 19

[andrew.luetgers]

I know this is stale but just discovered that the large performance difference of this code in Chrome and FireFox vs Safari probably comes down to GPU compositing. 

If you add some css to force the 100 rows (UL tags) into GPU composite layers the performance doubles. Inversely if you add the cells (LI tags) is cuts performance in half, to be expected its an abuse of the functionality with 10k elements.

This closes 90% of the performance gap. I have no idea how Safari goes about GPU compositing but a hunch from this observation is that seems to be doing something similar to what I describe above automatically.

Comment 20

[Dzmitry Malyshau [:kvark]]

Is this still a problem? We've made a lot of performance improvements since this issue was last updated. Please re-test.

Comment 21

[Mayank Bansal]

no response from the original reporter. And the jsfiddle link doesnt work anymore.
Closing for now.