[whatwg] Video Element Events? - Use Case: Custom Progress Bar

Ian Hickson wrote:
>> Video and audio playback is already extremely CPU intensive, we 
>> shouldn't require the UA to burn extra cycles doing unnecessary work.
> I agree. That was exactly the thinking behind the timeupdate event. It 
> allows the UA to determine how fast to update the UI without hurting 
> performance. Basically it puts the UA in charge of the performance 
> critical aspects instead of hoping that the author will work it out.

Though if all implementations are saying that it has the opposite effect 
then clearly we need to look into if something went wrong :)

I think one problem is that a timer can be set to fire much less often 
than the current time changes.

For example the UI doesn't need to be updated more than maybe twice a 
second for most videos (since it won't move more than one pixel in that 
time), whereas the timerupdate event sounds like it should fire with the 
framerate of the video, somewhere around 25-30 times per second.

/ Jonas

Received on Sunday, 16 November 2008 18:19:12 UTC