1461666 - Randomly scrolling gets quite janky

Status: RESOLVED WORKSFORME

(Core :: Panning and Zooming, defect, P3)

Description

[Kartikaya Gupta (email:[e-mail])]

macOS, running 60.0 beta. I find lately that just scrolling down simple pages will randomly jank quite heavily. I got a profile: https://perfht.ml/2KqsvTe

The URL I was scrolling in this instance was https://developer.mozilla.org/en-US/docs/Mozilla/QA/Automated_testing

Comment 1

[Kartikaya Gupta (email:[e-mail])]

Updated to 61.0b4 and I still see it. Same URL. Profile: https://perfht.ml/2KoMsJX

Comment 2

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

Speculating P2 and marking for QF triage.

Comment 3

[Andrew Overholt [:overholt]]

Does PLayerTransaction::Msg_Update mean "layerization" is at play here?

Comment 4

[Kannan Vijayan [:djvj]]

This is reproducible by :vchin on mac.  Does not show up on other platforms.  The issue is noticeable jank while scrolling up and down, when we are in/around the table area in particular.

Comment 5

[Kartikaya Gupta (email:[e-mail])]

It might be poor layerization of tables. Or it might just be expensive upload. If we get a layers dump and it shows a lot of layers then it's likely the former. If it's the latter it will probably be helped by bug 1265824. At the moment I'm not seeing the problem so I can't check which of the two cases it is. (But that in itself makes me lean towards the expensive upload scenario since that's more likely to be intermittent).

Comment 6

[Bas Schouten (:bas.schouten)]

Jamie, any thoughts here.

Comment 7

[Jamie Nicol [:jnicol]]

I'm on linux. I assume the underlying layerization issue is the same, but slow texture uploads make it more noticeable on mac. It still janks for me on Linux.

It looks to me like scrolling with the keyboard, or with the mouse wheel when the cursor is in the margins on the side of the page is fine. But if the cursor is over the content (the tables and above and below the tables) and we scroll with the wheel, then we create a new layer for all that content. In fact, just clicking on the content without scrolling is enough to cause this relayerization.

(If you enable layer borders and the apz minimap it's really easy to see what I mean.)

I assume this is because that content can scroll horizontally, so when it's scrolled (even vertically) the container becomes active and it gets its own displayport. But we probably don't want to do that unless we actually do scroll horizontally? Kats?

The other way to avoid jank would be to have it layerized that way from the start, but that would be wasteful when at rest or only scrolling vertically.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

(In reply to Jamie Nicol [:jnicol] from comment #7)
> I'm on linux. I assume the underlying layerization issue is the same, but
> slow texture uploads make it more noticeable on mac. It still janks for me
> on Linux.
> 
> It looks to me like scrolling with the keyboard, or with the mouse wheel
> when the cursor is in the margins on the side of the page is fine. But if
> the cursor is over the content (the tables and above and below the tables)
> and we scroll with the wheel, then we create a new layer for all that
> content. In fact, just clicking on the content without scrolling is enough
> to cause this relayerization.

This makes perfect sense, thanks for the investigation!

> I assume this is because that content can scroll horizontally, so when it's
> scrolled (even vertically) the container becomes active and it gets its own
> displayport. But we probably don't want to do that unless we actually do
> scroll horizontally? Kats?
> 
> The other way to avoid jank would be to have it layerized that way from the
> start, but that would be wasteful when at rest or only scrolling vertically.

Hm. There don't seem to be many good options here. I agree that we don't want it layerized that way from the start. Right now we layerize on certain types of input events, including wheel, touch, and mouse button events. In this case, where we're not actually scrolling horizontally, you're right that it should be avoidable. Implementing this is going to be a little tricky though. Right now, the unlayerized area is represented in APZ as a "dispatch to content" region, so if we hit-test an event to inside that area, APZ will wait for the main thread before processing that input event.

One possible optimization here is to allow APZ to distinguish between different kinds of "dispatch to content" regions - e.g. distinguish between regions that have DOM event listeners on them vs regions that are just inactive scrollframes. That might allow APZ to continue scrolling without having to wait for the main thread processing. This optimization would be easier with WebRender because we would just need to add a new flag to the CompositorHitTestInfo enum instead of adding a new event region which is more expensive.

But even in that case, the main thread processing will happen, and that's where the scrollframe is layerized. So the other possible optimization is to make that code smarter about when it actually does the layerization. e.g. for wheel events we could take into account whether the event would actually cause that scrollframe to start scrolling and only layerize in that scenario. I'm not sure offhand how complex that code would end up being but it's worth exploring at some point.

I suggest that for now we wait until the texture upload codepath is optimized on mac (that's being worked on actively) and then revisit this to see if it's better or we want to try implementing one or both of the above optimizations. I'll move this to the APZ component for now.

Comment 9

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

Looking at this during QF meeting. Kats thinks the texture upload work might land in time to help this on qf:64 timeframe.

Comment 10

[Vicky Chin [:vchin]]

I can't reproduce the jank anymore. Kats can you confirm?

Comment 11

[Kartikaya Gupta (email:[e-mail])]

Yup this seems much better now.