Bug 68769 - [mac] Timestamp parameter to requestAnimationFrame is busted in USE(REQUEST_ANIMATION_FRAME_TIMER) path
Summary: [mac] Timestamp parameter to requestAnimationFrame is busted in USE(REQUEST_A...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: James Robinson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-24 18:19 PDT by James Robinson
Modified: 2011-09-26 13:08 PDT (History)
6 users (show)

See Also:


Attachments
Patch (6.96 KB, patch)
2011-09-24 20:32 PDT, James Robinson
no flags Details | Formatted Diff | Diff
test that passes in chromium DRT (7.01 KB, patch)
2011-09-25 00:25 PDT, James Robinson
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
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 1 James Robinson 2011-09-24 20:32:03 PDT
Created attachment 108595 [details]
Patch
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.