Re: requestAnimationFrame

* Robert O'Callahan wrote:
>"Couldn't" is never an issue here. You can always use setTimeout as a
>backstop to ensure that your end-of-animation code runs even if
>requestAnimationFrame never fires a callback. My concern is that authors are
>likely to forget to do this even if they need to, because testing scenarios
>are unlikely to test switching to another tab in the middle of the
>animation.

The question was about what if you are guranteed that your script is run
if the tab resumes, but not necessarily before that. In that case the
code will always run, unless you did something crazy to detect whether
to run the end of animation code (for instance, instead of checking if
you are past 20 seconds, you check for whether you are between 20s and
30s to make your animation stop after 20s).

That seems much less a concern than that the model here is unclear. If
the model is "you can this and then the browser will magically do one
thing or another, we won't tell you the details" then people would have
a rougher time writing proper code than if the model was, say, "Upon
each call the callback must completely redraw everything and must not
depend on state modifications made from within the callback in any way".

It seems to me that end-of-animation problems are just another case of
state transition problems, you might aswell change something between
5s and 10s and depend on that having been executed at 13s (say you may
add a new element between 5s and 10s and fade it out again from 13s.)

Personally I am already horrified by the hoops one has to jump through
if one tries to synchronize audio playback and mozRequestAnimationFrame.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Wednesday, 24 November 2010 02:50:39 UTC