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

[Antti Koivisto]

On 16.11.2008, at 16:16, Ian Hickson wrote:

First of all, I'm not sure I fully understand the problem you are  
solving here. Could you summarize it?

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

If I want to update a time display once per second (which I think is  
fairly typical) why should I listen to a flood of events 60 times per  
second? On some devices those events and the Javascript that needs to  
run to filter them might consume substantial portion of the available  
CPU capacity.

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

As far as I see what you write below does not describe anything that  
would make the display more accurate or lighten the load. But perhaps  
you have some additional mechanism in mind that you did not document  
here?

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

The earlier iteration of the spec already fired timeupdate events on  
all discontinuous changes in time. How would this event flood be an  
improvement over that?

Any reasonable application will have its polling timer running only  
when the playback is actually in progress. The timer can be enabled  
and disabled based on changes in playback and ready state. (I have  
earlier suggested adding a state variable and associated simple event  
which would change state when continuous playback starts and end, for  
any reason, to make this easier to use).

Few other points:

- We cant require time update events to be frame accurate during  
continuous playback since there is no way to guarantee smooth playback  
with that requirement. If the events are not accurate they have no  
benefits over simple polling.
- Requiring events on every frame might make some playback  
optimizations impossible (by requiring constant activation of the web  
engine thread during playback).
- Any media synchronization mechanism should be considered as a  
separate issue.


   antti