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

[Ian Hickson]

On Tue, 28 Oct 2008, Charles Iliya Krempeaux wrote:
> 
> I was looking over the spec and looking to see how I'd go about creating 
> a custom "progress bar".  (Like you see as part of "scrub bars".)
> 
> To do this I'd imagine that a playing video would have to "send out" 
> events "fast enough" so that the progress bar could be updated "enough".
> 
> Perhaps I didn't read the spec carefully enough, but I don't see any 
> such event.

On Wed, 29 Oct 2008, Chris Double wrote:
> 
> You're looking for the 'timeupdate' event. This gets raised whenever the 
> current playback position changes. From the spec section 4.8.10.8:
> 
> "If the time was reached through the usual monotonic increase of the 
> current playback position during normal playback, the user agent must 
> then queue a task to fire a simple event called timeupdate at the 
> element. (In the other cases, such as explicit seeks, relevant events 
> get fired as part of the overall process of changing the current 
> playback position.)"
> 
> Although this is hidden away in the cue ranges section, it happens on 
> normal playback without cue ranges.

I've tried to make it less hidden.


On Fri, 31 Oct 2008, Eric Carlson wrote:
>
> I think requiring a user agent to post events as a movie plays is a 
> mistake. It will mean that *every* page will incur the overhead, even if 
> no scripts are listening for the events.

You don't have to fire the event if nobody is listening for it. (Browsers 
likely already have this implementation for mutation events if nothing 
else, so this shouldn't be that difficult to implement.)


> I understand that some pages will need to keep scripted UI in sync with 
> movie playback, but this can be done very easily with a JavaScript 
> timer:

The idea of the timeupdate event is actually to lighten the load on the 
user agent while simultaneously making the display more accurate than a 
timer could be.

With polling, the polling will miss key points, e.g. when the playback 
loops, which will result in the UI appearing to lag behind the playback. 
It will also cause higher processing cost while there is no need to send 
updates, e.g. while seeking or waiting for data, times where you really 
don't want extra load.


> Using a timer also allows a script to update at exactly the frequency 
> they need instead of at whatever frequency the UA happens to post 
> events.

Using a timer also allows them to go too fast. :-)


> 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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'