[webkit-reviews] review denied: [Bug 88638] requestAnimationFrame should only trigger when a new frame can be displayed. : [Attachment 151313] patch for review.

[bugzilla-daemon at webkit.org]

Simon Hausmann <hausmann at webkit.org> has denied Zeno Albisser
<zeno at webkit.org>'s request for review:
Bug 88638: requestAnimationFrame should only trigger when a new frame can be
displayed.
https://bugs.webkit.org/show_bug.cgi?id=88638

Attachment 151313: patch for review.
https://bugs.webkit.org/attachment.cgi?id=151313&action=review

------- Additional Comments from Simon Hausmann <hausmann at webkit.org>
I think the scheduleAnimation() interface should remain as-is and serve one
single purpose only: schedule an animation. I don't think it should at the same
time serve as a "decision" maker whether to fall back to timers or not. For our
purposes it is not even necessary to decide that for each scheduleAnimation()
call but instead it could simply live as a setting in WebCore::Settings. In WK1
we'd set a scheduleAnimationsWithTimer alike property to true, in WK2 we'd
leave it as false.

That way I think you could also avoid the #if PLATFORM(QT) in
WebChromeClient::scheduleAnimation(), making it easier for other ports that use
WK2 AC to re-use the same code path of properly synchronized RAF calls.