|Summary:||[mac] Timestamp parameter to requestAnimationFrame is busted in USE(REQUEST_ANIMATION_FRAME_TIMER) path|
|Product:||WebKit||Reporter:||James Robinson <jamesr>|
|Component:||New Bugs||Assignee:||James Robinson <jamesr>|
|Severity:||Normal||CC:||abarth, cmarrin, dglazkov, nduca, simon.fraser, webkit.review.bot|
|Version:||528+ (Nightly build)|
Description James Robinson 2011-09-24 18:19:53 PDT
The time parameter for requestAnimationFrame should be roughly equivalent to Date.now(), but in the USE(REQUEST_ANIMATION_FRAME_TIMER) path it has the wrong value. This is because animationTimerFired() passes a double value from WTF::currentTime(), which is in seconds since the epoch, to serviceScriptedAnimations() which expects to receive a DOMTimeStamp, which should be an unsigned long of milliseconds since the epoch. To convert the return value of WTF::currentTime() to a double you should use the helper convertSecondsToDOMTimeStamp()
Comment 2 WebKit Review Bot 2011-09-24 20:58:14 PDT
Comment on attachment 108595 [details] Patch Attachment 108595 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/9837495 New failing tests: fast/animation/request-animation-frame-timestamps-advance.html
Comment 3 James Robinson 2011-09-25 00:25:54 PDT
Created attachment 108601 [details] test that passes in chromium DRT
Comment 4 Simon Fraser (smfr) 2011-09-25 21:15:25 PDT
Comment on attachment 108601 [details] test that passes in chromium DRT View in context: https://bugs.webkit.org/attachment.cgi?id=108601&action=review > LayoutTests/fast/animation/script-tests/request-animation-frame-timestamps-advance.js:24 > + if (window.layoutTestController) > + layoutTestController.display(); display() doesn't do anything for rAF in Safari/Mac. We need to figure out a way to make rAF tests that work in Safari and Chromium.
Comment 5 James Robinson 2011-09-25 23:52:15 PDT
Comment on attachment 108601 [details] test that passes in chromium DRT This test does pass in both, the .display()s trigger the rAF in chromium and yielding to the message loop triggers the rAF in Safari. I think we should add a layoutTestController hook to trigger rAF callbacks, but it's a big pain in the butt to wire up layoutTestController additions to every build system so I haven't undertaken that task yet.
Comment 6 WebKit Review Bot 2011-09-26 00:20:51 PDT
Comment on attachment 108601 [details] test that passes in chromium DRT Clearing flags on attachment: 108601 Committed r95937: <http://trac.webkit.org/changeset/95937>
Comment 7 WebKit Review Bot 2011-09-26 00:20:56 PDT
All reviewed patches have been landed. Closing bug.
Comment 8 Simon Fraser (smfr) 2011-09-26 10:08:23 PDT
(In reply to comment #5) > I think we should add a layoutTestController hook to trigger rAF callbacks, but it's a big pain in the butt to wire up layoutTestController additions to every build system so I haven't undertaken that task yet. Would adding the hook to window.internals make sense?
Comment 9 James Robinson 2011-09-26 13:08:09 PDT
I think yes - I was thinking of adding something to layoutTestController since that's where .display() is, but since this is supposed to exercise WebCore logic exclusively I guess window.internals would make sense.