Bug 114501 - AnimationController: set timer delay to 0.016 in the BlackBerry port
Summary: AnimationController: set timer delay to 0.016 in the BlackBerry port
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-12 03:32 PDT by Alberto Garcia
Modified: 2013-04-15 03:28 PDT (History)
5 users (show)

See Also:

Attachments
Patch (1.14 KB, patch)
2013-04-12 03:35 PDT, Alberto Garcia 		no flags Details | Formatted Diff | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Alberto Garcia 2013-04-12 03:32:12 PDT 
The BlackBerry is set to 60fps instead of 40.
Comment 1 Alberto Garcia 2013-04-12 03:35:35 PDT 
Created attachment 197741 [details]
Patch

This would be the trivial option, but I think anilsson has a better proposal, can you comment?
Comment 2 Alberto Garcia 2013-04-12 03:36:21 PDT 
Updating bug title since it affects cross-platform code.
Comment 3 Arvid Nilsson 2013-04-12 03:40:47 PDT 
The thing I told berto about was: Another approach we have been discussing at BlackBerry is to hook up the AnimationController to the requestAnimationFrame mechanism. Then it would not have to use a Timer at all, and wouldn't have to hard code any timeout.

It would perhaps be good if we could prioritize the tasks performed when RAF fires, so that JS handlers fire first (so they can start/stop animations, modify DOM etc) and then the AnimationController gets to run its native handlers.
Comment 4 Arvid Nilsson 2013-04-12 03:41:34 PDT 
CC'ing Simon for his input
Comment 5 Simon Fraser (smfr) 2013-04-12 09:18:04 PDT 
AnimationController does use requestAnimationFrame for CSS animations: bug 64591, if the platform supports them.
Comment 6 Arvid Nilsson 2013-04-15 03:24:30 PDT 
(In reply to comment #5)
> AnimationController does use requestAnimationFrame for CSS animations: bug 64591, if the platform supports them.

Thank you very much Simon - that's very useful! We can drop our local timer timeout tweak as soon as we pick up the fix for 64591.

Marking this as invalid.
Comment 7 Arvid Nilsson 2013-04-15 03:28:42 PDT 
(In reply to comment #3)
> The thing I told berto about was: Another approach we have been discussing at BlackBerry is to hook up the AnimationController to the requestAnimationFrame mechanism. Then it would not have to use a Timer at all, and wouldn't have to hard code any timeout.
> 
> It would perhaps be good if we could prioritize the tasks performed when RAF fires, so that JS handlers fire first (so they can start/stop animations, modify DOM etc) and then the AnimationController gets to run its native handlers.

It's interesting to see that the developers on bug #64591 chose to let the AnimationController animations fire first, and only then service JS animations. I'm sure there's good arguments for doing it that way around, too.