I've seen this a couple of times. Most recently I had a single window open to about:blank and WebRenderBridgeParent::SampleAnimations() was returning non-zero transform or opacity. I don't know how to reproduce and maybe the recent animation work will just fix this.

This happened to me again on a more recent build so it seems like the problem still exists.

This happened to me again today

Here's a mostly useless profile: https://perfht.ml/2k38XJu

Here's a page on which we go at 60fps with webrender but don't composite in layers. It's a pretty common pattern I think, where you have a spinner or loading indicator implemented by a infinite rotation transform on an element, and then just set visibility:hidden on it when you don't want it to show. In both layers and WR, we build the display list at 60fps but in layers I guess DLBI realizes that there's no visible difference and doesn't end up recompositing. With WR however we do end up recompositing.

Actually it might not be DLBI. I need to trace the code a bit more.

It was the layer tree invalidation in the compositor. So I guess even without WR we do a bunch of work (display list building, layer building, layer transaction) for this kind of animation. It's only the last step in the composite pipeline that gets skipped.

I did not saw high fps with attachment 8985163 [details]. But I saw high fps with the following. Even when the animation was not shown by scrolling the page, it continue to composite with 60fps. https://www.kirupa.com/html5/looping_a_css_transition.htm

(In reply to Sotaro Ikeda [:sotaro] from comment #8) > I did not saw high fps with attachment 8985163 [details]. > This case has been optimized by other bugs (e.g. bug 1471174) > But I saw high fps > with the following. Even when the animation was not shown by scrolling the > page, it continue to composite with 60fps. > https://www.kirupa.com/html5/looping_a_css_transition.htm This case will be optimized by bug 1246045 soonish.

(In reply to Hiroyuki Ikezoe (:hiro) from comment #9) > (In reply to Sotaro Ikeda [:sotaro] from comment #8) > > I did not saw high fps with attachment 8985163 [details]. > > This case has been optimized by other bugs (e.g. bug 1471174) Gah. why quoted? :/

Anyway, an important thing here is that, though I've been optimizing various kind of animations in styling (to be precise the optimizations skip styling entirely), there are a bunch of cases we don't yet optimized. An example is in bug 1456389 comment 7. I think this bug is for such cases. I mean an optimization in graphics layer.

I think there are separate bugs here. I originally filed this bug about WebRender getting stuck continuously painting at 60fps regardless of the content. i.e. Even when the only tab open is about:blank we're still painting at 60fps.

See also bug 1473592

Just being in autoscroll mode without actually scrolling lets gfx.webrender.debug.new-frame-indicator freak out.

(In reply to Jeff Muizelaar [:jrmuizel] on parental leave until at least June 25 from comment #12) > I think there are separate bugs here. I originally filed this bug about > WebRender getting stuck continuously painting at 60fps regardless of the > content. i.e. Even when the only tab open is about:blank we're still > painting at 60fps. If this is the case, it means either there's an animation in the UI that we didn't terminate properly (in which case there's a bug in the RemoveEpochDataPriorTo codepath to clear individual animations), or there's an animation from some content that didn't get cleaned up when the tab was closed (in which case there's a bug in the ClearResources/RecvClearCachedResources codepath). Or it's not an animation problem at all, but something else. To take the first step of distinguishing between these three cases and hopefully narrow down STR, I wrote a patch that associates some "debug info" (the URL and element the animation came from) with the animation, and so if you run into this problem you can flip a pref and get some spew to stderr that tells you which element is animating. Please apply the patch to your local builds and if you run into the problem you can turn on the gfx.webrender.debug.stuck-animations pref and get check stderr. I wrote this patch with the intention of landing it, but most people won't run Nightly in a way that they can see the stderr so I don't know how valuable that would be.

I havne't seem this for a while. I'm going reduce the priority.

Bug 1478643 has an example to cause this. It's a purely animation bug.

This doesn't seem to happen anymore.

\o/