1465792 - TaskCluster animation triggers constant WebRender activity

Status: NEW

(Core :: Graphics: WebRender, defect, P3)

Description

[:gerard-majax]

STR:
 1. Ubuntu 18.04, Core i7-8650U with WebRender
 2. Open a TaskCluster task or taskgroup with running tasks

Expected:
 Animation should not consume too much

Actual:
 According to my laptop's fan, there is a lot of activity.

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

Comment 1

[:gerard-majax]

I think that it also happens when the tab is not visible, but that the animation would be visible if the tab was active. That means, scrolling down to make the animation out of the visible zone, there's much less activity.

Comment 2

[:gerard-majax]

Profile with the animation out of the visible zone: https://perfht.ml/2kCL4sh

Comment 3

[Aria Beingessner [:Gankra]]

just confirming, this doesn't peg your fan when running without webrender?

Comment 4

[:gerard-majax]

(In reply to Alexis Beingessner [:Gankro] from comment #3)
> just confirming, this doesn't peg your fan when running without webrender?

As much as I can remember, not that much. I just had a new look at that, I'm still reproducing the issue.

Obviously, investigating in a taskcluster page got me some interesting bits:
 - there's an "active" class applied to the "Running" element in the top of the page,
 - this is responsible for a small animation
 - remove the "active" class actually makes the load decrease a lot: going from ~66% of CPU to ~3% of CPU.

Comment 5

[:gerard-majax]

Just re-verified on current BuildID=20180709100247, there's slight, but ~6% Compositor and main process activity on the same page.

Comment 6

[:gerard-majax]

(In reply to Alexandre LISSY :gerard-majax from comment #5)
> Just re-verified on current BuildID=20180709100247, there's slight, but ~6%
> Compositor and main process activity on the same page.

Same build, WebRender re-enabled,
 - main process ~130% CPU
 - WRRenderBackend, Renderer threads each ~40% CPU,
 - WRSceneBuilder ~20% CPU

Now, I understand that linux is not the current stabilization priority, so I cannot tell how of this is actually dependant on the webpage itself or on unoptimized platform code path.

It seems, though, that now, when the tab is not visible, even if the element triggering the activity is in the visible viewport, there is much less cpu activity

Comment 7

[:gerard-majax]

Seems like there's some CSS animation: "progress-bar-stripes"

Comment 8

[Aria Beingessner [:Gankra]]

Yeah it's pretty clear to us why this is slow in webrender. We currently don't support async animation of this property so it's causing a constant scene rebuild. Just not the highest priority right now.

My coworkers were also surprised this wasn't also super cpu-intensive in vanilla gecko (since they didn't think it supported it either).

Comment 9

[Dustin J. Mitchell [:dustin] (he/him)]

This is a bootstrap animation
  https://getbootstrap.com/docs/3.3/components/#progress-animated

Does that page also use a lot of CPU with the animation toggled on?  If so, and if https://getbootstrap.com/docs/4.1/components/progress/ does too, maybe it's worth a bug report to bootstrap.

Comment 10

[:gerard-majax]

(In reply to Dustin J. Mitchell [:dustin] pronoun: he from comment #9)
> This is a bootstrap animation
>   https://getbootstrap.com/docs/3.3/components/#progress-animated
> 
> Does that page also use a lot of CPU with the animation toggled on?  If so,
> and if https://getbootstrap.com/docs/4.1/components/progress/ does too,
> maybe it's worth a bug report to bootstrap.

Clicking "Toggle animation" reproduces the exact same behavior as on TaskCluster, for me :)

Comment 11

[Jeff Muizelaar [:jrmuizel]]

It isn't clear what a good solution to this will be. There's general work happening that will help with this but I'm not sure there's anything specific to be done for the MVP.