1307262 - slow animations at https://coolstar.org/misc/mikurain/

Status: RESOLVED WORKSFORME

(Core :: Web Painting, defect)

Description

[Asa Dotzler [:asa]]

From twitter thread https://twitter.com/coolstarorg/status/782985715088883712 I tested https://coolstar.org/misc/mikurain/ and it is indeed slower in latest nightly Firefox than in latest release of Chrome.

Comment 1

[Asa Dotzler [:asa]]

Additional versions of the test case locked at 30fps and 15fps

https://coolstar.org/misc/mikurain/index-30fps.html
https://coolstar.org/misc/mikurain/index-15fps.html

Comment 2

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Hello, I'm asking your help with an experiment with making decisions on bugs. You've been needinfo'ed on this bug. I'd like you to take one action to help this bug make progress toward a decision. The things you can do include:

* If you know or have a good guess of which product and component this bug belongs to, change the product and component of the bug
* If you know of the right person to ask about this bug, redirect the needinfo to them
* If you cannot reproduce the bug, close it

All we need you to do is one thing that will help us make a decision on the bug or resolve it.

Thank you for your help with this. If you have questions, please contact [e-mail].

Comment 3

[:Gijs (he/him)]

Profile: https://perfht.ml/2rewRpS

From a quick look, we seem to be spending all our time painting (though I bet it doesn't help that the JS on that page seems to set a height we can't parse which spams the JS console if you open that, and that it uses setTimeout/setInterval rather than requestAnimationFrame). Matt, can you take a look and/or forward to someone who might know what's up here?

Asa: if you run into this type of perf stuff again, recording a profile and putting it in either Core or Firefox *Untriaged* (rather than General) and adding the [qf] whiteboard tag will make sure it gets some eyeballs.

Comment 4

[Jean Gong :jgong]

Bas,can you take a look at this and see if shows something more serious.

Comment 5

[Matt Woodrow (:mattwoodrow)]

It looks like we're using the 'single tile' content client, and frequently re-allocating the buffer due to resizes. That's probably also costing us in terms of redrawing the content too.

We should probably have a way to detect frequent size changes, and make sure we use real tiling.

Comment 6

[Bas Schouten (:bas.schouten)]

It sounds from Matt's comment like we know roughly what causes this, the solution sounds like a good idea as well.

Matt do you understand why those resizes happen? I don't see anything obvious in this animation being resized.. Also when I look at this with layer borders on, I mainly see weird stuff going on at the bottom with layers. But the spatters traveling upwards seem to be in fixed size layers as well.

Having said that this many layers seems like it might be a concern for perf either way.

Comment 7

[Matt Woodrow (:mattwoodrow)]

I guessed resizes based on the callstacks, where we were spending a lot of time allocating.

Looking at the page with layer borders, I see us frequently adding and removing one or more layers that cover a large portion of the screen. It's probably those that we're allocating and clearing for.

Comment 8

[Naveed Ihsanullah [:naveed]]

Do we need telemetry on this layer behavior to determine if this happens a lot?

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: testcase 2

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: testcase 3 (just the "splash" pixels, with FPS display)

Comment 12

[Daniel Holbert [:dholbert]]

I took some FPS measurements on Windows 10 using the attached "testcase 3".  I let it run for ~20 seconds (waiting for the testcase's FPS counter to mostly stabilize & hover around a single consistent value). In my tests, the named browser is the only app running.

RESULTS::
 - Chrome 61 dev channel:    48 FPS
 - Edge 40 (EdgeHTML 15):    35 FPS
 - Firefox Nightly 56:       23 FPS

Comment 13

[Markus Stange [:mstange]]

(In reply to Daniel Holbert [:dholbert] from comment #11)
> Created attachment 8878216 [details]
> testcase 3 (just the "splash" pixels, with FPS display)

In this testcase, createSplash() doesn't assign a height property to the splash object, so the line 'obj.element.style.height = obj.height + "px";' causes a CSS property parse error, and the profile shows significant overhead from processing those errors.
I haven't looked at the other testcases or checked whether that bug is present in the original page.

Comment 14

[Daniel Holbert [:dholbert]]

Attachment: testcase 4 (removing bogus "height" assignment"

Good catch! That is indeed a bug in the original site, too (for the "splash" objects).

After fixing that in the testcase, we improve by 2-4 FPS it seems (not by a lot).

Comment 15

[Daniel Holbert [:dholbert]]

(In reply to Naveed Ihsanullah [:naveed] from comment #8)
> Do we need telemetry on this layer behavior to determine if this happens a lot?

Sorry, I don't know the layers code well enough to have a good answer for this (or to know whether there's a single coherent problem that we've identified here yet).  But to me, it feels like these two thing are about the same amount of work:
 (a) investigating to figure out what the correct thing to measure in telemetry would be, to find out how many sites are affected by this bug.
 (b) investigating/diagnosing and fixing the bug.

So, that makes me lean towards telemetry not being super useful here.

(RE what to measure -- Matt had mentioned seeing some layer borders (from about:config pref layers.draw-borders) covering large area of the screen & that possibly being responsible for the jank here.  I do see those large borders on the original testcase & "testcase 1", but my "testcase 3" and "4" do not show these & is still extra-janky in Firefox (compared to other browsers).  So I'm not entirely sure that's the root problem here.)

Comment 16

[Daniel Holbert [:dholbert]]

Attachment: testcase 4 (removing bogus "height" assignment", for real now)

Comment 17

[Gregory Pappas [:gregp]]

This seems to run fine now. Asa, do you still see issues?
https://share.firefox.dev/3UV3ZOE

Comment 18

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.