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
<[EMAIL PROTECTED]> 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
