transform animations stutter on linux

RESOLVED WONTFIX

Status

()

defect
RESOLVED WONTFIX
10 months ago
2 months ago

People

(Reporter: malithyapa, Assigned: nical)

Tracking

61 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

Reporter

Description

10 months ago
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.
Reporter

Updated

10 months ago
Component: Untriaged → Graphics: Layers
Product: Firefox → Core
Reporter

Updated

10 months ago
Flags: needinfo?(dbolter)
Nical is on triage this week.
Flags: needinfo?(dbolter) → needinfo?(nical.bugzilla)
Assignee

Comment 2

10 months ago
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.
Flags: needinfo?(malithyapa)
Reporter

Comment 3

10 months ago
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.
Flags: needinfo?(malithyapa)
Reporter

Comment 4

10 months ago
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
Assignee

Comment 5

10 months ago
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
Flags: needinfo?(nical.bugzilla)
Assignee

Comment 6

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

Updated

10 months ago
Assignee: nobody → nical.bugzilla
Assignee

Comment 8

10 months ago
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 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.
Attachment #9002735 - Flags: review+
Comment on attachment 9002736 [details]
Bug 1483459 - Don't needlessly copy regions in ContainerLayer::GetIntermediateSurfaceRect. r=sotaro

Sotaro Ikeda [:sotaro] has approved the revision.
Attachment #9002736 - Flags: review+

Comment 11

10 months ago
Pushed by nsilva@mozilla.com:
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
Assignee

Updated

10 months ago
Keywords: leave-open
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

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

Flags: needinfo?(nical.bugzilla)
Assignee

Comment 14

2 months ago

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

Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Flags: needinfo?(nical.bugzilla)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.