1239943 - Scrolling pdfs in Google docs is very janky

Status: RESOLVED WORKSFORME

(Core :: Panning and Zooming, defect)

Description

[Jeff Muizelaar [:jrmuizel]]

https://drive.google.com/file/d/0Bzm_4XrWnl5zOXdTcUlEMmdZem8/edit

The scroll bar moves smoothly but the pdf does not.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

I noticed something like this scrolling the side bar of https://www.tensorflow.org/versions/master/tutorials/recurrent/index.html#introduction

Comment 2

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

I think profiles would help here. I loaded the pages with the FPS counter enabled and they don't appear to fall back to main-thread scrolling (per the visual indicator from bug 1053992) which was my first guess.

Comment 3

[Jeff Muizelaar [:jrmuizel]]

I also see it here: https://www.khronos.org/registry/webgl/sdk/tests/webgl-conformance-tests.html?version=2.0.0.

It looks like it may have to do with subframe scrolling and that it's a regression.

Comment 4

[Jeff Muizelaar [:jrmuizel]]

It turns out this was caused by setting velocity bias to 0

Comment 5

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

(In reply to Jeff Muizelaar [:jrmuizel] from comment #4)
> It turns out this was caused by setting velocity bias to 0

I can reproduce it with this. And that's really bizarre. I can look into it.

Comment 6

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

Doesn't seem to happen on Linux with the scroll wheel. Although there the minimap also doesn't update, so there might be something fishy going on here.

Comment 7

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

So I think what's going on here is that the PaintedLayer (in the khronos.org page) is also marked as fixed-position, and so the async transform generated by the APZ gets clobbered by the fixed-pos-ness. I'm not entirely sure how the velocity bias pref comes into play, but I think it might be that with the pref enabled we do more repaints on the main thread and so the issue is less noticeable?

I commented out the call to SetShadowTransform in TranslateShadowLayer, so as to make the fixed-pos-ness a no-op and that fixed the problem for me locally.

Comment 8

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

Bug 1231538 will probably fix the fixed-pos issues. I'm still curious to know exactly why the velocity bias pref caused a change in behavior though. Pretty sure it's related to repaint frequency.

Comment 9

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

Bug 1238805 explains why the velocity bias results in more painting. It will be fixed by bug 1192910. This means that if bug 1192910 lands before 1231538, this bug will manifest even with a nonzero velocity bias before it gets fixed. If land in the other order the bug will be fixed for all cases first.

Comment 10

[Botond Ballo [:botond]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #7)
> So I think what's going on here is that the PaintedLayer (in the khronos.org
> page) is also marked as fixed-position, and so the async transform generated
> by the APZ gets clobbered by the fixed-pos-ness.

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #8)
> Bug 1231538 will probably fix the fixed-pos issues.

Agreed. This sounds like the same issue as bug 1238571, which I expect to be fixed by bug 1231538.

Comment 11

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

Bug 1231538 will be in tomorrow's nightly, flagging myself to retest on that.

Comment 12

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

This looks fixed in the latest nightly, via 1231538.

Comment 13

[Jeff Muizelaar [:jrmuizel]]

Yep, looks fixed to me as well.