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
