Bug 72145 - Interval between 'timeupdate' events is sometimes too long
Summary: Interval between 'timeupdate' events is sometimes too long
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Media (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Eric Carlson
URL:
Keywords:
Depends on:
Blocks: 71648
  Show dependency treegraph
 
Reported: 2011-11-11 09:50 PST by Eric Carlson
Modified: 2011-11-14 18:14 PST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Carlson 2011-11-11 09:50:15 PST
The spec says the 'timeupdate' events should fire during playback at least every 250ms:

If the time was reached through the usual monotonic increase of the current playback position during normal playback, and if the user agent has not fired a timeupdate event at the element in the past 15 to 250ms and is not still running event handlers for such an event, then the user agent must queue a task to fire a simple event named 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.)

We use a repeating timer to fire these events, but it goes off every 250ms so we don't allow any time for event processing and events are sometimes fired late.
Comment 1 Eric Carlson 2011-11-14 18:14:28 PST
(In reply to comment #0)
> 
> We use a repeating timer to fire these events, but it goes off every 250ms so we don't allow any time for event processing and events are sometimes fired late.

It may be worth decreasing the timer interval bit there is no way to guarantee a minimum interval between events because our timer could be delayed for GC, layout, swapping, or any number of time consuming tasks.