1265880 - Adjust velocity bias to see if checkerboarding improves

Status: RESOLVED FIXED

(Core :: Panning and Zooming, defect)

Description

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

The apz.velocity_bias pref controls how much the displayport request is offset from the current scroll position based on the user's scroll velocity. It seems like in some cases this is too much; we should adjust this value to see how it impacts checkerboarding in the wild (using the telemetry probes for checkerboarding).

Comment 1

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

Attachment: MozReview Request: Bug 1265880 - Drop the APZ velocity bias to 0 on desktop. r?mstange

Review commit: https://reviewboard.mozilla.org/r/52838/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/52838/

Comment 2

[Markus Stange [:mstange]]

Comment on attachment 8752869 [details]
MozReview Request: Bug 1265880 - Drop the APZ velocity bias to 0 on desktop. r?mstange

https://reviewboard.mozilla.org/r/52838/#review49724

Comment 3

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

I tried to post this comment earlier but apparently failed to:

The telemetry experiment is still too heavyweight for my liking and it doesn't look like the people with the power to change it have any interest in doing so. I'm just going to flip the pref to 0 on desktop and keep an eye on the regular telemetry dashboard to see if there's an impact. If the telemetry experiment process improves later we can still do an experiment to see what value is best.

Comment 4

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/83e8b01535bf

Comment 5

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/83e8b01535bf

Comment 6

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

For the record, Botond looked at the telemetry stats around this change and observed that the checkerboarding duration went up slightly when this landed. We also noticed that the checkerboarding peak went down slightly, and the checkerboarding severity metric remained roughly the same. The interpretation is that we made checkerboards longer but take up less of the screen.

Botond theorized that this was because we now have a few pixels of checkerboarding consistently while scrolling, because we are closer to the edge of the displayport. Whereas before we would have shorter but larger areas checkerboarded, in those cases where the velocity bias prediction was wrong.

We agreed that the new situation is probably better than the old situation, since it's more consistent and likely less noticeable to the user. However I suspect that maybe a small amount of velocity bias might be even better. We should probably still run an experiment with a few different values (0.25, 0.5, 0.75) to see what we get. However it's pretty low priority and we have other fish to fry.

Comment 7

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

Comment on attachment 8752869 [details]
MozReview Request: Bug 1265880 - Drop the APZ velocity bias to 0 on desktop. r?mstange

Approval Request Comment
[Feature/regressing bug #]: APZ
[User impact if declined]: Slightly worse checkerboarding in some conditions
[Describe test coverage new/current, TreeHerder]: No test coverage, but we have telemetry data on how this impacts the user experience. It seems to indicate a small positive effect
[Risks and why]: very low risk, just a pref modification that has been baking for a month
[String/UUID change made/needed]: none

Comment 8

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8752869 [details]
MozReview Request: Bug 1265880 - Drop the APZ velocity bias to 0 on desktop. r?mstange

Improve the product, early in the cycle, taking it.
Should be in 48 beta 3

Comment 9

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

https://hg.mozilla.org/releases/mozilla-beta/rev/f403cf3a053a