Currently the APZC physics for B2G are off on the nexus 7. The deceleration on a fling is very sudden and a large change from pre APZC. This bug should be a good chance to merge some of the APZC values between fennec, b2g pre APZC, b2g with APZC and metro. It's ok for platforms to differ if they require it but right now some differences are simply unintentional. We have values in preference but b2g and metro seem to use difference preferences so merging that would be good. Also some of the gesture detecting value use different threshold.

Is this still an issue? I believe it may have at least been partially mitigated by the fixes in bug 962278.

We discussed the APZC physics with Gordon from Gaia UX at the gfx work week. Here are some bits of Gordon's summary. Bug 907123 is the "flywheel scrolling" thing so I'm adding that as a dependency here as it is part of the overall physics model. We should break the overscroll stuff out into a separate bug too but that can wait until we have a better idea of what we will use as the basic force model. Scroll physics: * Currently uses linear damping with speed caps at low and high ends * Issue: Too fast for slow / too slow for fast * Will need some kind of force model in platform * Discussed force models: spring, dampened spring, magnet, Verlet integration, etc. * Fix your timestep * Use step debounce function to tune for different devices rather than having per-device exceptions in the force model. * We will need to tune the physics for best feel. Find the right physical analogy. Milan suggests working closely with platform and perhaps prototyping force model with JavaScript, Flash or some other low-cost tool. Flywheel scrolling: * Feasible * Moving great distances will cause checkerboarding * Could mitigate using a low-res "motion blur" effect by stretching low-res tiles until we can render content. Fx Android had this at one point. * Force model: reduce damping vs increase speed? Overscroll: * Distinction between effect vs physics vs integration. Can work on these independently. * Must be integrated with APZC physics

Here are my thoughts after fiddling with available apz scrolling prefs: * pref("apz.max_velocity_pixels_per_ms", 0.07) helps dispel feeling that your speed is being capped, but this may not be a problem once we have flywheel scrolling. * pref("apz.fling_friction", 0.003); gives you a more comfortable scroll when fine-tune scrolling, but aggressive flicks feel like they should be faster. * The phantom jog bug 949859 seems unaffected by these settings. It also throws the feel of fine-tune scrolling way off. * Flywheel scrolling will likely change the feeling of scrolling significantly, so tuning this should happen in conjunction with tuning flywheel scrolling (bug 907123). I have a hunch that applying a shallow curve function to the fling velocity may feel better than 1:1 extrapolation; or maybe a simple physics integrator is the answer. However, in conjunction with Flywheel scrolling I think we may be able to arrive at some combo of "good enough" tunings w/ current physics model for the 2.0 timeline.

Might as well change these now. We can always change them again later if necessary.

Comment on attachment 8413973 [details] [diff] [review] Update pref values Review of attachment 8413973 [details] [diff] [review]: ----------------------------------------------------------------- ::: b2g/app/b2g.js @@ +898,5 @@ > // more often than the default value (100). > pref("apz.asyncscroll.throttle", 40); > pref("apz.pan_repaint_interval", 16); > > +// APZ physics settings, tuned by UX people s/people/designers? =p

:) Updated, carrying r+. Will flag checkin-needed since m-i is closed.