2003845 - if the anchored content is only compensating for scroll be smart about assigned the ASR of the anchor only if it helps

Status: NEW

(Core :: Graphics: WebRender, enhancement)

Description

[Timothy Nikkel (:tnikkel)]

We currently only have the ability to async scroll in both directions or neither direction, but anchored frames can compensate for scroll in only one direction. We could improve this by deciding not to assign the ASR of the anchor to the anchored frame if it will result in incorrect async scrolling in one direction.

Say if we only compensate in the horizontal axis, and the only ancestor scroll frames that contain the anchor but not the anchored frame (the set of ancestor scroll frames of the anchor is a superset of the ancestor scroll frames of the anchored frame) can only scroll vertically we would decide not to assign the ASR of the anchor to the anchored frame because we would get no benefit from it.

The also suffers from the same problem mentioned in bug 2003843 in that the decision to assign ASR or not makes things much more complicated.

Comment 1

[David Shin[:dshin]]

Benefits aside (Which I understand as ASR tree being more predictable), would keeping things the way it is have a perf implication?
If I understand this right, there shouldn't be a correctness issue with this, at least?

Comment 2

[Timothy Nikkel (:tnikkel)]

(In reply to David Shin[:dshin] from comment #1)

Benefits aside (Which I understand as ASR tree being more predictable), would keeping things the way it is have a perf implication?

Keeping things as they are right now would not have a perf implication. Implementing this bug would make finding the ASR slower, and would stop us from doing async scrolling in some cases where the user could async scroll in the "wrong" direction, but it would also prevent async scrolling in the correct direction (async scrolling can be considered a perf issue in that it keeps scrolling smooth). So implementing this bug would make things slightly slower but improve correctness in that the user doesn't seen async scrolling in a wrong direction which then gets fixed up by a main thread update.

If I understand this right, there shouldn't be a correctness issue with this, at least?

There is in that the anchored content will get async scrolled in a non-compensated direction, and then when things sync up with the main thread the async scrolling would get undone. I haven't tested it, but it would look/feel glitchy to the user. This bug would aim to eliminate that problem.

Comment 3

[Timothy Nikkel (:tnikkel)]

Attachment: oneaxis.html

Comment 4

[Timothy Nikkel (:tnikkel)]

With the testcase it's not as bad as I thought (when the main thread is not blocked), but we do trigger the overscroll bounce animation a lot.

Comment 5

[Timothy Nikkel (:tnikkel)]

I think it's probably not overscroll bounce, but rather that is how it looks when the compositor and the main thread "fight" over the position of those elements. The fact that it feels a bit like overscroll is probably a good thing as it feels less like glitchy behaviour even if it is still incorrect.

Comment 6

[Timothy Nikkel (:tnikkel)]

I had an idea: I think we can use the scroll linked effects (because that is basically what is happening here) machinery to improve this.