[whatwg] Video Element Events? - Use Case: Custom Progress Bar
jonas at sicking.cc
Sun Nov 16 18:19:12 PST 2008
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.
More information about the whatwg