Open Bug 1465792 Opened 6 years ago Updated 4 months ago

TaskCluster animation triggers constant WebRender activity

Categories

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

defect

Tracking

()

People

(Reporter: gerard-majax, Unassigned)

References

(Blocks 1 open bug)

Details

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
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.
Profile with the animation out of the visible zone: https://perfht.ml/2kCL4sh
just confirming, this doesn't peg your fan when running without webrender?
(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.
Just re-verified on current BuildID=20180709100247, there's slight, but ~6% Compositor and main process activity on the same page.
(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
Flags: needinfo?(a.beingessner)
Seems like there's some CSS animation: "progress-bar-stripes"
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).
Flags: needinfo?(a.beingessner)
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.
(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 :)
Priority: P2 → P3
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.
Blocks: stage-wr-next
No longer blocks: stage-wr-trains
Severity: normal → S3
Blocks: wr-investigate-perf
No longer blocks: stage-wr-next
You need to log in before you can comment on or make changes to this bug.