1442801 - scrollBy() has not been updated to take advantage of APZ, unless called with parameter behavior: smooth

Status: UNCONFIRMED

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

Description

[philipmorant]

User Agent: Mozilla/5.0 (Windows NT 10.0; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20180206200532

Steps to reproduce:

Addon code (WebExtensions) scrolls the page programmatically using window.scrollBy(1,1).

about:config confirms that APZ is enabled:
layers.async-pan-zoom.enabled: true


Actual results:

The page scrolls correctly, but is subject to jank.


Expected results:

As determined during discussion on #apz irc channel, window.scrollBy() does not make an APZ call unless invoked with the parameter behavior: 'smooth'.

window.scroll(), window.scrollByLines(), window.scrollByPages(), Element.scrollTop+= and Element.scrollLeft-= can all be used to scroll.  One might want to check whether they are coded to use APZ yet.

( I was asked to raise this bug in Core :: Panning and Zooming, but was unable to find any field where that could be specified. )

Comment 1

[Botond Ballo [:botond]]

(In reply to philipmorant from comment #0)
> ( I was asked to raise this bug in Core :: Panning and Zooming, but was
> unable to find any field where that could be specified. )

Sorry, I meant "Core" product and "Panning and Zooming" component.

Comment 2

[Botond Ballo [:botond]]

(In reply to philipmorant from comment #0)
> As determined during discussion on #apz irc channel, window.scrollBy() does
> not make an APZ call unless invoked with the parameter behavior: 'smooth'.

To clarify what is being requested here: right now, if you do a scrollBy() call with behavior 'instant', that request is sent to compositor with the next layers transaction. This means that if the scrollBy() triggers a paint, and that paint is long, we're only going to update the scroll position visually once the paint is done.

It was suggested that we could instead send the new scroll position to the compositor right away, allowing it to visually update the scroll position even if it means checkerboarding because the content is not painted yet.

Now, when we were discussing this on IRC, I envisioned something like a single scrollBy() call with a large delta. The proposed change would allow the scroll position to be updated visually faster in a case like that.

If the use case is a sequence of scrollBy() calls with small deltas, and they're triggered by something like JS mouse event handlers or requestAnimationFrame callbacks, the proposed change wouldn't help, because those handlers / callbacks run on the same thread as paints (the content process main thread), so even though the first one would be sent right away, if that triggers a long paint, the remaining ones will still be sitting in a queue behind the paint.

Nonetheless, the proposed change seems useful for some use cases (e.g. single scrollBy() with a large delta), so we can keep this bug open.

Comment 3

[philipmorant]

Thanks Botond, that's much, much clearer.

As regards multiple small deltas there's a thing called AnimationWorklets (https://wicg.github.io/animation-worklet/), currently work in progress. These run on the compositor thread. The problem would then be reduced to what extent the browser queue-jumps events ahead of paint operations. Presumably the design goal is that all user-initiated events are given priority. But I'm getting off-topic.

Assuming that this is a relatively easy change, then it seems to me that one might as well take advantage of all the great work that was put into APZ.