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

[Jonas Sicking]

Eric Carlson wrote:
> Ian -
> 
> On Oct 28, 2008, at 10:36 PM, Chris Double wrote:
> 
>> On Wed, Oct 29, 2008 at 5:22 PM, Charles Iliya Krempeaux
>> <supercanadian at gmail.com> wrote:
>>>
>>> Perhaps I didn't read the spec carefully enough, but I don't see any 
>>> such
>>> event.
>>
>> 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 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.
> 
>   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:
> 
>     document.addEventListener('play', updateTimeDisplay, true);
>     document.addEventListener('pause', updateTimeDisplay, true);
> 
>     function updateTimeDisplay()
>     {
>         var vid = document.getElementById('video');
>     
>         if (!vid.paused && !vid.ended && vid.networkState > 
> HTMLMediaElement.HAVE_FUTURE_DATA)
>             setTimeout(updateTimeDisplay, 200);
>        
>         // update display here
>     }
> 
>   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.
> 
>   Video and audio playback is already extremely CPU intensive, we 
> shouldn't require the UA to burn extra cycles doing unnecessary work.

I agree. For the normal as-time-passes changes to currentTime I don't 
think an event is needed. When currentTime is changed either directly or 
though looping (if we end up supporting some type of looping) it makes 
sense to dispatch an event.

/ Jonas