Closed Bug 1239943 Opened 8 years ago Closed 8 years ago

Scrolling pdfs in Google docs is very janky

Categories

(Core :: Panning and Zooming, defect)

Product:
Core
Component:
Panning and Zooming
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: jrmuizel, Unassigned)

References

Details

(Whiteboard: [gfx-noted]) 

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

The scroll bar moves smoothly but the pdf does not.
I noticed something like this scrolling the side bar of https://www.tensorflow.org/versions/master/tutorials/recurrent/index.html#introduction
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.
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.
Whiteboard: regression, regression-window-wanted
It turns out this was caused by setting velocity bias to 0
(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.
Whiteboard: regression, regression-window-wanted
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.
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.
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.
Depends on: 1231538
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.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) 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:kats@mozilla.com) 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.
See Also: → 1238571
Bug 1231538 will be in tomorrow's nightly, flagging myself to retest on that.
Flags: needinfo?(bugmail.mozilla)
This looks fixed in the latest nightly, via 1231538.
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(bugmail.mozilla)
Resolution: --- → WORKSFORME
Yep, looks fixed to me as well.
You need to log in before you can comment on or make changes to this bug.