On Mar 29, 2011, at 2:23 PM, Rik Cabanier wrote:
> On Tue, Mar 29, 2011 at 12:13 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> On Wed, Mar 30, 2011 at 6:30 AM, Rik Cabanier <cabanier@gmail.com> wrote:
> The second part of your problem is a little different. In order to do that, you need to have a precise timing event so you can determine if your character is colliding with something else.
> Mozilla's proposal could be part of the solution: http://hacks.mozilla.org/2010/08/more-efficient-javascript-animations-with-mozrequestanimationframe/
> This proposal lets you call a JS function at precise intervals much like Flash's onEnterFrame function. If you combine this with my request to pause all animations on the page, you would know the precise state of everything in the DOM.
>
> I think requestAnimationFrame is tremendously useful (I helped design it) but it can't be a complete solution since when animations are carried out off the HTML5 event loop thread (which you want for smoothness), JS may not be able to run at the moment the animation finishes.
>
> This is why being able to pause all animations is important.
> I don't think that this will give many issues with smoothness as long as you use animations for the bulk of the motion and keep you JavaScript to a minimum.
> The Flash player pauses all rendering during its ActionScript phase and real world performance of games and animations is fine.
WebKit on Safari and iPhone renders some animations on another thread, at display-refresh frequency (60fps). Dropped frames are very noticeable with such animations. Pausing animations while JS is running is simply not an option for us.
Simon