1483459 - transform animations stutter on linux

Status: RESOLVED WONTFIX

(Core :: Graphics: Layers, defect)

Description

[malithyapa]

Attachment: Screenshot from 2018-08-15 11-26-29.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180704003137

Steps to reproduce:

Disclaimer: may not be a bug, but this problem is only visible in firefox, linux. Performance is really good on other platforms and other major browsers. 

1) apply 'will-change: transform' to 3 div elements with cover background picture (approximately 990k pixels in total)
2) transform along y axis (all three divs at the same time):
         transition: transform 800ms cubic-bezier(0.9,0.1,0.1,0.4);
         transform: translateY(-1800px);


Actual results:

There's an inconsistent but visible stutter in the animation.
Performance monitor doesn't always show a reduction of fps to correlate with the stutter.
But there is always a 'CC Graph Reduction' event around the same time i notice the stutter.


Expected results:

I'm certain that this issue is due to hardware compositing not being enabled in firefox by default for linux. Leaving that as is, is it possible that garbage collection and compositing is happening on the same thread? which would cause a stutter in compositing while garbage collection is happening?

IF that's the case (i know next to nothing about browser internals) perhaps garbage collection can be put off until animations are completed for platforms which hardware compositing is not enabled?

Any tips on the user side to further improve animation smoothness would also be very much appreciated.

Comment 1

[David Bolter [:davidb] (NeedInfo me for attention)]

Nical is on triage this week.

Comment 2

[Nicolas Silva [:nical]]

Malithyapa, could you profile the performance issue using the gecko profiler addon? There are instructions here: https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler

Once you have the profiler installed you can capture a profile and share a link to it from the UI, which will let us investigate what is happening on your computer (I quickly tried to reproduce locally but I didn't get the stutter, probably because I only have a beefy CPU handy at the moment, or maybe I didn't write the test case properly).

Also if you could attach the test case to this bug it would help make sure we are looking at the same thing.

> I'm certain that this issue is due to hardware compositing not being enabled in firefox by default for linux. Leaving that as is, is it possible that garbage collection and compositing is happening on the same thread? which would cause a stutter in compositing while garbage collection is happening?

GC and compositing are never happening on the same threads, although GC can delay things that start an animation (but once the animation is driven by the compositor it shouldn't be affected by GC).

You can try to enable opengl compositing by setting the pref "layers.acceleration.force-enabled" to true in about:config. This will at least let you confirm your suspicion that the GL compositor isn't affected.

Comment 3

[malithyapa]

Hi Nicolas, thanks a lot for the response!

> You can try to enable opengl compositing by setting the pref
> "layers.acceleration.force-enabled" to true in about:config. This will at
> least let you confirm your suspicion that the GL compositor isn't affected.

Setting force-enabled to true does resolve the problem. Been waiting for a long time for this to be enabled by default :/

Here's the profile of one instance i noticed a stutter. 
https://perfht.ml/2nR2X8q

However at a glance i can't find anything that correlates with the stutter from the profile. The stutter (most visible) occurs within the 1.8s 2s timeframe.

Here's fiddle with a similar case

https://jsfiddle.net/mailithyapa/4ybf7g9u/43/

In the above test case i can notice a visible stutter about 20% of the time. 
Have to reload everytime though because in the actual scenario the items are added to the dom just before the animation begins.

Comment 4

[malithyapa]

I noticed that there's a bunch of other stuff happening in the profile i shared earlier. So here's a profile of the test case above at a time i noticed a significant stutter. 

https://perfht.ml/2nSPOf5

Comment 5

[Nicolas Silva [:nical]]

aside from spending a looong time creating/initializing shmem layer textures (page faulting I suppose) on the content thread [1], the most striking thing is that we tend to needlessly spend an entire milisecond on the compositor copying a region for no good reason [2]. It might not fix things but it should be a low hanging fruit and shoving 1 ms off a lot of compositor frames is very appealing.



[1]: https://perf-html.io/public/d6bc0bf79c1aa6e4939bf5e76709d67318c63de7/calltree/?globalTrackOrder=0-1-2-3-4&hiddenGlobalTracks=2-3&localTrackOrderByPid=24640-0~&range=0.3980_0.4712~0.4234_0.4436&thread=5&v=3

[2]: https://perf-html.io/public/d6bc0bf79c1aa6e4939bf5e76709d67318c63de7/calltree/?globalTrackOrder=0-1-2-3-4&hiddenGlobalTracks=2-3&localTrackOrderByPid=24640-0~&range=0.4746_1.3003~1.1747_1.1827~1.1749_1.1827&thread=1&v=3

Comment 6

[Nicolas Silva [:nical]]

Attachment: Bug 1483459 - Avoid copying regions before converting them to rects throughout the gfx directory. r=sotaro

This patch was generated using a simple sed script:
sed -i 's/ToUnknownRegion().GetBounds()/GetBounds().ToUnknownRect()/g' gfx/**/*.cpp gfx/**/*.h

Comment 7

[Nicolas Silva [:nical]]

Attachment: Bug 1483459 - Don't needlessly copy regions in ContainerLayer::GetIntermediateSurfaceRect. r=sotaro

Comment 8

[Nicolas Silva [:nical]]

Hm, the default sampling interval for the profiler makes it a bit hard to actually claim that we are spending a whole ms in there but it's still worth removing the pointless allocations and memcpys there. Other than that the compositor is pretty much spending all of its time writing blitting layers in skia and it's not immediately obvious how to improve upon this with the software compositor backend.

Comment 9

[Sotaro Ikeda [:sotaro]]

Comment on attachment 9002735 [details]
Bug 1483459 - Avoid copying regions before converting them to rects throughout the gfx directory. r=sotaro

Sotaro Ikeda [:sotaro] has approved the revision.

Comment 10

[Sotaro Ikeda [:sotaro]]

Comment on attachment 9002736 [details]
Bug 1483459 - Don't needlessly copy regions in ContainerLayer::GetIntermediateSurfaceRect. r=sotaro

Sotaro Ikeda [:sotaro] has approved the revision.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/cf82ec49ee1a
Don't needlessly copy regions in ContainerLayer::GetIntermediateSurfaceRect. r=sotaro
https://hg.mozilla.org/integration/mozilla-inbound/rev/3db3f0761004
Avoid copying regions before converting them to rects throughout the gfx directory. r=sotaro

Comment 12

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

https://hg.mozilla.org/mozilla-central/rev/cf82ec49ee1a
https://hg.mozilla.org/mozilla-central/rev/3db3f0761004

Comment 13

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

The leave-open keyword is there and there is no activity for 6 months.
:nical, maybe it's time to close this bug?

Comment 14

[Nicolas Silva [:nical]]

It's hard to improve upon the blitting performance with the software compositor, WebRender will be our way to address this.