Tap-to-zoom should possibly have an animation where it slightly overshoots the targeted area to have a nice animated bump that indicates exactly where it ends (and looks cool).
Created attachment 143247 [details] Patch
Comment on attachment 143247 [details] Patch Clearing flags on attachment: 143247 Committed r117951: <http://trac.webkit.org/changeset/117951>
All reviewed patches have been landed. Closing bug.
Please revert this, it doesn't match any other browser, and adds to perceived jerkiness of the animation. If anything, we should expose an experimental property of the WebView that lets you control the easing curve from QML, eg if the platform has a standard curve for zoom-animations.
Do you mean perceived jerkiness when the animation stutters or also when it is smooth? And is the animation acceptable when the viewport is only zooming in and out? I believe this is the case, and is has a WIP patch to only overshoot on zoom and not on panning-like motion of the viewport, since that does look odd.
(In reply to comment #5) > Do you mean perceived jerkiness when the animation stutters or also when it is smooth? > > And is the animation acceptable when the viewport is only zooming in and out? I believe this is the case, and is has a WIP patch to only overshoot on zoom and not on panning-like motion of the viewport, since that does look odd. Hmm, I didn't realize it also applies when a programmatic pan/scroll is applied.. that's even worse :/ The perceived jerkiness is primarily when the animation also stutters, but in both cases the curve conflicts with the behavior of a regular Flickable, where overshoots happen when you actually cross the bounds of the flickable. This change adds a overshoot-like curve for the case where you scroll or zoom perfectly within the bounds of the page. In addition, the curve is "less neutral", from a UX-pov, if you think about no-animation -> linear animation -> cublic animation -> bounce-animation, so as a default I think it assumes too much about the target platform's UX. That's why i suggested we make the curve configurable, if we see the need for the target platform to override this.
Created attachment 145560 [details] Patch
Comment on attachment 145560 [details] Patch Attachment 145560 [details] did not pass qt-wk2-ews (qt): Output: http://queues.webkit.org/results/12900184
Comment on attachment 145560 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=145560&action=review > Source/WebKit2/UIProcess/qt/QtViewportInteractionEngine.cpp:297 > + m_scaleAnimation->setEasingCurve(QEasingCurve::OutCubic); > m_scaleAnimation->setEasingCurve(easingCurve); The second call seems to be redundant.
Created attachment 145568 [details] Patch
Comment on attachment 145568 [details] Patch Clearing flags on attachment: 145568 Committed r119390: <http://trac.webkit.org/changeset/119390>