Bug 87108 – [Qt] Tap-to-zoom overshoot animation

• Component: WebKit2
• Status: RESOLVED FIXED

[Allan Sandfeld Jensen]

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).

[Allan Sandfeld Jensen]

Created attachment 143247 [details]
Patch

[WebKit Review Bot]

Comment on attachment 143247 [details]
Patch

Clearing flags on attachment: 143247

Committed r117951: <http://trac.webkit.org/changeset/117951>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Tor Arne Vestbø]

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.

[Allan Sandfeld Jensen]

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.

[Tor Arne Vestbø]

(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.

[Allan Sandfeld Jensen]

Created attachment 145560 [details]
Patch

[Early Warning System Bot]

Comment on attachment 145560 [details]
Patch

Attachment 145560 [details] did not pass qt-wk2-ews (qt):
Output: http://queues.webkit.org/results/12900184

[Andras Becsi]

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.

[Allan Sandfeld Jensen]

Created attachment 145568 [details]
Patch

[WebKit Review Bot]

Comment on attachment 145568 [details]
Patch

Clearing flags on attachment: 145568

Committed r119390: <http://trac.webkit.org/changeset/119390>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.