W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > March 2011

[Bug 12267] Make video state transitions happen in the same task as firing events

From: <bugzilla@jessica.w3.org>
Date: Thu, 10 Mar 2011 16:06:07 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1PxiNL-0004Ji-Dq@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12267

--- Comment #7 from Eric Carlson <eric.carlson@apple.com> 2011-03-10 16:06:05 UTC ---
  Programming with media is hard, shrug, but I don't think pretending otherwise
will help. There is no way to paper over the fact that state *does* change
asynchronously so we should help developers understand this and deal with it. 

  An extreme example is that of a video which is playing when a modal dialog is
shown, playback continues and events are queued but not delivered. Scripts that
run when the dialog is dismissed will see the state of the movie at the time
the dialog was shown - how can this be helpful?

> In short, if not all properties are frozen, they can become internally
> inconsistent as seen from scripts. Freezing one property would require freezing
> them all instantaneously, or they could stil become inconsistent. Freezing all
> of them means always calculating the buffered array even though it may not be
> used, which is a bit wasteful.
> 
  Do you propose to "freeze" the currentTime property too? This will lead to
very strange behavior when the time jumps around relative to the wall clock,
eg. it will be pinned when an event is pending and will instantaneously catch
up the once the last event is posted. Imagine a plot of the delta between the
wall clock and currentTime during normal playback.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Thursday, 10 March 2011 16:06:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 10 March 2011 16:06:13 GMT