In bug 571822, we changed to fire timeupdate events less frequently than once per frame. We now fire them every 250ms. A value called TIMEUPDATE_MS defines how frequently they happen. Research shows that humans perceive delays of < 100ms as basically instantaneous, but can notice delays of more than that: http://stackoverflow.com/questions/536300/what-is-the-shortest-perceivable-application-response-delay (see various answers for research papers). In doing some work with popcorn.js, which is a video-driven web page events framework, I notice the "roughness" of a 250ms resolution for timeupdate. "Coordinated" events seem to happen at a slightly different time each time I play the video. If I say "now" in the video and want something to happen at the same time in the page, that's hard. (A whatwg email from dolske suggests this may be a different issue or different #define, but I also notice the non-evenness of the update of the time in the video controls, if you mouse over the video and watch the timer increment. This imprecision makes the controls seem inaccurate.) I realise once per frame is wrong, and I realise that upping this value too high has performance consequences. I know other browers fire it less frequently (every 200 or 250ms), but as long as we are not firing it once per frame (which might lead people into the false assumption that this is how it's supposed to work), I think there's no risk of misleading web developers. So I think we should set TIMEUPDATE_MS to 100. Gerv

I thought 200ms was considered the perseivale limit? What's the limit in our refresh driver?

See the 3rd or 4th comment in the Stack Overflow question. I remember hearing 100ms from elsewhere as well. We can ask some of the UX team if you need more confirmation. Gerv

One of the reasons for the change was to ensure developers don't rely on the timeupdate event for anything that requires synchronisation. Since other browsers don't fire at a low rate there's the danger that developers will test on Firefox and not on other browsers and not realise their application does not work cross browser. Developers should use setTimeout or setInterval if they want something regularly updated or synchronised.

If they should use setInterval to get regularly updated, then what's the use case for the timeupdate event?

None that I know of. There was discussion about what use it is on the WHATWG list but it didn't go anywhere: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-October/023901.html

Can we just remove it then? Is there content out there that relies on it. If people want to do things like progress bars and other things synchronized with the video, the new animation API seems like a better solution.

An every-frame timer would be useful because if you want an event to happen every frame with SetTimeout, you have to set the timeout to be rather higher resolution than the frame rate, to make sure you catch every frame and there's no drift. This is inefficient. However, it looks like the other browsers are not interested in this use case, so it's not going to happen. (I.e. anyone wanting to do this will have to do it the inefficient way.) So, if we are not going to have an every-frame timer, I agree that the use case for onupdate is weak. I guess it's useful to have the event automatically stop and start happening when the video is playing or not playing. But that state is also queryable from JavaScript. Gerv

Hi Gerv, we had the same problem in Popcorn.js where timeupdate wouldn't fire frequently enough to do good looking animation. What we ended up doing was adding a flag to the Popcorn.js constructor that enabled an internal requestAnimationFrame loop instead of a timeupdate loop. Please see http://popcornjs.org/popcorn-docs/media-properties/#frameanimation for documentation. Because Popcorn.js was the usecase for lowering the timeupdate delay specified in the bug, would it be appropriate to close this bug now?

OK. Gerv