- From: Brian Campbell <brian.p.campbell@dartmouth.edu>
- Date: Fri, 6 Nov 2009 14:02:31 -0500
On Nov 6, 2009, at 6:16 AM, Simon Pieters wrote: > On Fri, 06 Nov 2009 11:05:03 +0100, Robert O'Callahan <robert at ocallahan.org > > wrote: > >> On Fri, Nov 6, 2009 at 10:44 PM, Philip J?genstedt >> <philipj at opera.com>wrote: >> >>> We've considered firing it for each frame, but there is one >>> problem. If >>> people expect that it fires once per frame they will probably >>> write scripts >>> which do frame-based animations by moving things n pixels per >>> frame or >>> similar. Some animations are just easier to do this way, so >>> there's no >>> reason to think that people won't do it. This will break horribly >>> if a >>> browser is ever forced to drop a frame, which is going to happen >>> on slower >>> machines. In balance this may or may not be a risk worth taking. >>> >> >> That's possible, but we haven't noticed authors doing that yet. > > http://people.mozilla.com/~prouget/demos/round/index.xhtml Hmm. That's a quick and dirty demo that just does a silly effect on each frame. It should be dependent on the current time of the video, as should any animation; for instance, if that demo worked at all on WebKit, it would go glacially slowly. Anyone who does animation that depends on their update function being called at a constant rate is going to be broken; are we trying to avoid that case? Is there anyone out there who uses setInterval and increments anything a constant amount each time, rather than basing progress on how much time has actually elapsed? I agree that there is some concern here, but I'm wondering how much it's worth worrying about. No matter what, there aren't any hard guarantees about how much time will elapse between timeupdate events (the thread could block for some reason, the user could scrub the video, the video could stall or be paused). And no matter what, if timeupdate events come in at any sort of regular rate (whether it be the frame rate, or an arbitrary rate like 4 or 30 times per second, or if they bypass timeupdate entirely and just use setInterval), there are going to be some people who mistakenly assume that they can just do a constant increment each time they are called. So, I think those users will have errors whether or not timeupdate happens once per frame or at some other interval. Anyhow, for my purposes, once per frame, or 30 times per second, or anything like that, are all fairly reasonable. 4 updates per second means that I'm just going to have to replace it with setInterval, and am much more likely to forget to disable that setInterval when, say, the video is paused, leading to extra wasted CPU cycles. -- Brian
Received on Friday, 6 November 2009 11:02:31 UTC