1457413 - Scroll jank due to slow paint on gsmarena.com animation

Status: RESOLVED FIXED

(Core :: Graphics, defect, P3)

Description

[Mark]

Attachment: scroll jank gsmarena.com.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180323154952

Steps to reproduce:

Probably re-opening bug 1410461

www.gsmarena.com has an animation in the sidebar (see screenshot attached). The animation slides into & out of view as the page scrolls. On Firefox Mac 59.0.2 (and other Mac versions) the sliding animation causes a huge scroll jank with WebRender OFF. Looking in the devtools Performance screen there seems to be very slow painting when the animation takes place. The FPS can drop to single digits and some paints take many hundreds of ms, screenshot shows a 444 ms paint during the animation.

The problem exists at default & scaled resolutions but might be worse at scaled resolutions.

With WebRender ON the problem disappears and the scrolling is smooth.

Comment 1

[Mark]

I can't upload perf.html profiles ATM, it gets stuck on symbolification, I don't understand. So I've saved the profile and attached it. I hope it works. 

In the Marker Chart I see a lot of BHR-detected hang of up to 270 ms and the refresh driver gets stuck for a similar duration. I think that's my scroll jank.

I've also attached a screen grab of the Marker Chart.

Comment 2

[Mark]

Attachment: Firefox 2018-04-27 12.00 profile.sps.json.gz

Comment 3

[Mark]

Attachment: BHR hangs in profile.png

Comment 4

[Markus Stange [:mstange]]

(In reply to Mark from comment #1)
> I can't upload perf.html profiles ATM, it gets stuck on symbolification, I
> don't understand.

(This might be bug 1414383. If you have Xcode installed, try starting it once and accepting the license.)

Comment 5

[Mark]

Yep that fixed it, thanks

https://perfht.ml/2FndQVU

250 ms BHR-detected delays (whatever that means, doesn't sound good but I know nothing) each time I swipe and the sidebar box animates. Scroll linked effect problem? Pretty nasty scroll jank on the real page. I think it's worse at high scaled resolutions, up to 500 ms delay sometimes. WebRender OFF; 1280x800; MacBookPro 11,1; Nightly 2018-04-27.

Comment 6

[Cosmin Muntean [:cmuntean], Ecosystem QA]

User Agent  Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:59.0) Gecko/20100101 Firefox/59.0
Firefox 59.0.2, Build ID: 20180323154952

I have tested this issue on latest Firefox 59.0.2 release and latest Nightly (61.0a1) build, but I haven't managed to reproduce this issue. 

Mark, can you please retest this using a new Firefox profile (https://goo.gl/AWo6h8), maybe even safe mode (https://goo.gl/AR5o9d), to eliminate custom settings as a possible cause?

Mike, can you please take a look at the provided performance profile from comment 5?

Comment 7

[Mark]

I see the same problem with a new version of Nightly 2018-05-01 downloaded to the desktop of a newly created user and run from there, i.e. a completely clean Nightly version with no add-ons except Gecko profiler:- big jank as the box animates and BHR-detected delays of ~300 ms on the content thread.

I switched on opacity using gfx.compositor.glcontext.opaque TRUE
   -> problem persists, jank and ~300 ms BHR-hangs

I switched Nightly to using Low Resolution mode by cmd-I on its icon and selecting "Open in Low Resolution mode"
   -> problem goes away, scrolling is butter smooth and no BHR-detected hangs in the profile.

If I switch WebRender ON
   -> problem goes away, ditto

I'm using a MacBookPro 11,1 at default 1280x800 Retina resolution. So a fairly old Retina machine with a fairly weak iGPU. MacOS 10.13.4.

Higher resolutions do seem to make the problem worse, Low Resolution Mode makes the problem go away. 

I keep an eye on my GPU power consumption and animating that box causes a big spike in GPU power.

So... a Retina scaling issue? GPU maxing out? How come, with an opaque window & talking to the GPU via OpenGL?

see bug 1422090, bug 1429522 etc etc

Hope someone can replicate it. Cheers

Comment 8

[Mark]

I don't see the problem on my older non-Retina MacBook Pro from circa 2009. So, just a Retina resolution issue?

Comment 9

[Mike Conley (:mconley) (:⚙️)]

Here's what I see:

1. https://perfht.ml/2HNMVV9: Long GPU upload times on the compositor thread on macOS, because we're copying memory over to it. That should hopefully be made better by bug 1265824.
2. https://perfht.ml/2HRlMRk: Very long paints. Some of these seem to be because we're allocating shared memory because we ran out of texture clients, and had to allocate more. 
3. https://perfht.ml/2HNNyOv: There's also a long pause while we flush async paints. Unfortunately, we're not capturing the paint threads in this profile, so it's not clear why.

At any rate, all of this falls pretty squarely within the Graphics component.

Comment 10

[Mark]

I don't see a paint thread in the perf.html using either FF 59.0.2 or Nightly 61. layers.omtp.enabled is true, all the omtp values are default, WebRender is off. Do I need to turn anything on in the profiler?

Comment 11

[Mark]

https://perfht.ml/2K2uVag

with paint thread. Several scrolls up and down so repeated tests of the ~300 ms jank.

Comment 12

[Sotaro Ikeda [:sotaro]]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #9)
> 2. https://perfht.ml/2HRlMRk: Very long paints. Some of these seem to be
> because we're allocating shared memory because we ran out of texture
> clients, and had to allocate more. 

From the stack it spent time for setting 0xFF000000 to B8G8R8X8 format buffer for Skia.
  https://dxr.mozilla.org/mozilla-central/source/gfx/layers/BufferTexture.cpp#490

Comment 13

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #12)
> (In reply to Mike Conley (:mconley) (:⚙️) from comment #9)
> > 2. https://perfht.ml/2HRlMRk: Very long paints. Some of these seem to be
> > because we're allocating shared memory because we ran out of texture
> > clients, and had to allocate more. 
> 
> From the stack it spent time for setting 0xFF000000 to B8G8R8X8 format
> buffer for Skia.
>  
> https://dxr.mozilla.org/mozilla-central/source/gfx/layers/BufferTexture.cpp#490

:lsalzman, do we still need it?

Comment 14

[Lee Salzman [:lsalzman]]

(In reply to Sotaro Ikeda [:sotaro] from comment #13)
> (In reply to Sotaro Ikeda [:sotaro] from comment #12)
> > (In reply to Mike Conley (:mconley) (:⚙️) from comment #9)
> > > 2. https://perfht.ml/2HRlMRk: Very long paints. Some of these seem to be
> > > because we're allocating shared memory because we ran out of texture
> > > clients, and had to allocate more. 
> > 
> > From the stack it spent time for setting 0xFF000000 to B8G8R8X8 format
> > buffer for Skia.
> >  
> > https://dxr.mozilla.org/mozilla-central/source/gfx/layers/BufferTexture.cpp#490
> 
> :lsalzman, do we still need it?

Skia absolutely requires that the alpha channel must be filled with opaque values. So this would entirely depend on the question of whether the downstream consumer of this shmem is always clearing it, in its entirety, with opaque values before use. If this is not the case, then we can't remove the mandatory clear.

This is a consequence of the fact that Skia upstream is not willing to support a true BGRX mode, so we just have to fake it.

Comment 15

[Sotaro Ikeda [:sotaro]]

:rhunt, is it possible to move alpha channel initialization to paint thread if the paint thread is used?

Comment 16

[Ryan Hunt [:rhunt]]

Yes it is possible, but I'm not sure that would help here.

It will take the same amount of time on the paint thread to clear the alpha channel as it will on the main thread, and the paint thread looks like it's already busier than the main thread in this profile.

That is, we are blocking in FlushAsyncPaints because the paint thread is still working when a new paint wants to happen [1]. If we move this work to the paint thread, we might just end of blocking in FlushAsyncPaints longer.

[1] https://perfht.ml/2ImbjNW

Comment 17

[Mark]

Chrome is butter smooth on the same animation. How does Chrome + Skia handle this?  

...  or is that a naive question ;)

Comment 18

[Matt Woodrow (:mattwoodrow)]

I had a play with this, the problem happens when the sidebar changes to have position:fixed.

When the sidebar is scrolling, the whole page is painted into a single layer.

When the sidebar switches to position:fixed, we separate that into a new layer, and also separate everything above the sidebar (in DOM order) into a layer. Unfortunately this 'above' section is the majority of the page content.

We do this since we assume that async scrolling might move the position:fixed content under the above content, but we don't have code to detect that there's no horizontal scrolling and that it can't actually happen.

From there we try to allocate tiles for all the new layers, exhaust the tile pool and have to actually allocate some of the tiles.

Allocations are slow, clearing the new tiles is slow, and then we have to repaint all the old tiles (to remove the above content), plus all the new tiles.

That's a lot of newly painted pixels, and we have to upload them all which takes a while. Bug 1265824 should make this faster.

Fixing FrameLayerBuilder to know that the sidebar can't ever intersect the scrolled content would be the best thing to do here.

Comment 19

[Mark]

Yes I experimented with one of the trys for bug 1265824 and it seemed to substantially fix this gsmarena.com bug. Looking forward to bug 1265824 landing properly.

Comment 20

[Matt Woodrow (:mattwoodrow)]

Filed bug 1477148 for one possible solution to the texture pool problem.

Comment 21

[Mark]

I wonder if the problems here are similar to those on the new reddit...  bug 1459875. 

What they have in common is that both seem to hit my Mac's iGPU very hard. Looking at my GPU power consumption it goes very very when the gsmarena.com sidebar is animating during a scroll, and also when r/firefox is loading or scrolling. I think the high GPU consumption is not related to the opacity and Core Animation stuff affecting Macs, because it happens even with an opaque Firefox context and at default resolution, a configuration which does not normally tax my GPU.

This is with gfx.allow-texture-direct-mapping true.

Comment 22

[Markus Stange [:mstange]]

Resolving this bug as fixed because the scroll jank was fixed by bug 1265824. The other problems mentioned here already have their own bugs.