Spinoff from https://bugzilla.mozilla.org/show_bug.cgi?id=975831#c19 - Ben Kelly suggested putting a velocity cap to limit how fast we can scroll, thereby limiting the chances of running into checkerboarding. Seems like a reasonable idea so I'm spinning out a dedicated bug for it.

Thanks for filing kats! I'll take this since its simple enough for me to do and I imagine you guys are busy with heavier lifting in gfx for tiling, etc.

Initial patch introducing the velocity limitation and preference. I'm going to see if I can write a gtest for this before asking for review.

Add the preference to b2g so it can be easily tuned. Took me a bit to realize float values must be specified as strings in the file.

Comment on attachment 8380656 [details] [diff] [review] bug976035_part1_max_velocity.patch Review of attachment 8380656 [details] [diff] [review]: ----------------------------------------------------------------- ::: gfx/layers/ipc/Axis.cpp @@ +96,5 @@ > } > > void Axis::UpdateWithTouchAtDevicePoint(int32_t aPos, const TimeDuration& aTimeDelta) { > float newVelocity = mAxisLocked ? 0 : (mPos - aPos) / aTimeDelta.ToMilliseconds(); > + float cappedVelocity = std::min(newVelocity, gMaxVelocity); I'd like there to be a way to explicitly disable it too. I think if gMaxVelocity < 0 then just use newVelocity without capping it. Also make gMaxVelocity -1 by default so that on non-b2g platforms no pref changes are needed to keep the current behaviour. b2g.js can set it to 6.0 to cap it on b2g.

Excellent point. Updated to treat negative values as unlimited velocity. Defaults to unlimited velocity.

Comment on attachment 8380709 [details] [diff] [review] bug976035_part1_max_velocity.patch (v2) Review of attachment 8380709 [details] [diff] [review]: ----------------------------------------------------------------- Pre-emptive r+. It might be a bit hard to write a test for this code so I'd rather land the patch now and worry about that later.

Comment on attachment 8380700 [details] [diff] [review] bug976035_part2_b2g_pref.patch Review of attachment 8380700 [details] [diff] [review]: ----------------------------------------------------------------- Would be good to check if this is suitable for higher DPI devices like the nexus 4 and nexus 5 as well.

Try build before pushing: https://tbpl.mozilla.org/?tree=Try&rev=a6fca7526089 Also starting a nexus4 build locally to test there. Since I have never flashed this nexus4, though, I probably will not hold up landing this if I run into problems with the device.

Nom for 1.4? to help mitigate checkerboarding issues.

Try was green. Still working on my nexus-4, but even if the setting is not quite right there I don't think we want to hold it back from our main release phones. Ultimately we probably need a device-specific pref strategy, but thats a separate bug. Landed in b2g-inbound: remote: https://hg.mozilla.org/integration/b2g-inbound/rev/8db8eddda6f8 remote: https://hg.mozilla.org/integration/b2g-inbound/rev/bc2c4bd25713

https://hg.mozilla.org/mozilla-central/rev/8db8eddda6f8 https://hg.mozilla.org/mozilla-central/rev/bc2c4bd25713

Note, scrolling does seem a bit slow with this in place on the nexus-4. Perhaps we need to adjust this to be something like device-screens/second and then calculate the corresponding pixels/ms. Kats, what do you think?

Kats away until 3/6. BenWa, Botond?

(In reply to Ben Kelly [:bkelly] from comment #12) > Note, scrolling does seem a bit slow with this in place on the nexus-4. > Perhaps we need to adjust this to be something like device-screens/second > and then calculate the corresponding pixels/ms. That sounds reasonable to me. I'm happy to review a patch that does this.

Thanks. I'll write a new bug up tonight.