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

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12267

Robert O'Callahan (Mozilla) <roc@ocallahan.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |roc@ocallahan.org

--- Comment #22 from Robert O'Callahan (Mozilla) <roc@ocallahan.org> 2011-05-17 04:28:07 UTC ---
I support the changes mentioned in this bug. As noted, what Simon has proposed
is pretty close to (but a definite improvement on) what Firefox already does.

> As I said, you can't stop the world while the scripts think (e.g. freeze the
> video), and snapshotting the world is just telling you a truth about the past,
> not the present.

Every browser is taking snapshots and returning "truths about the past". Most
browsers take a snapshot of each individual property, and take a new snapshot
every time each property is accessed. Firefox takes one snapshot of the entire
state (conceptually; the implementation is smarter than that) and uses that
snapshot for the duration of the HTML5 task. The advantage of our approach is
that it guarantees the script sees a view of the state that's consistent across
properties and across the duration of the HTML5 task.

For example, the following code snippets are guaranteed to be equivalent in
Firefox, but not in other browsers:
  a.time = video.currentTime;
  b.time = video.currentTime;
and
  a.time = b.time = video.currentTime;
I think preserving "obvious" equivalences like that is worth having, meets
author expectations and will avoid script bugs.

Another example: the following code is guaranteed to work in Firefox (at least
not throw due to t not being seekable), but not in other browsers:
  var timeRanges = video.seekable;
  if (isInTimeRanges(t, timeRanges)) {
    video.currentTime = t;
  }
(We achieve this by guaranteeing not to evict data from the media cache during
the execution of an HTML5 task.)

(In reply to comment #13)
> (In reply to comment #10)
> > The best behavior of currentTime isn't obvious, I'll agree thus far. Are there
> > any use cases for scripts observing currentTime changes while they are running?
> 
> A script that displays captions, subtitles, slides, etc, in sync with a playing
> video? Keeping relatively accurate sync is hard enough, why make it worse?

Please forgive me for repeating Philip, but Web apps with long-running HTML5
tasks don't work. Even in an aggressive multiprocess, multithreaded browser
implementation, such apps can't respond to user input or update any of their
rendering apart from video (since browsers guarantee that only the state of the
page between HTML5 tasks is rendered). The only way for an app to be responsive
and stay in sync with other activity is to issue a series of very short-lived
HTML5 tasks. That's why using one snapshot per task works well in practice.

Echoing what Philip said in comment #18, state changes performed by the script
should certainly be reflected immediately in the script's view of the video
state.

[Ideally I think we would buffer the side effects and make sure they're applied
atomically at the end of the HTML5 task. Consider the following code:
  <audio id="audio1" ... muted></audio>
  <audio id="audio2" ...></audio>
  ...
  audio2.muted = true;
  audio1.muted = false;
Authors would expect this to switch audio streams with no detectable overlap or
gap. We should provide that. However, that goes way beyond the scope of this
bug, so pretend I didn't mention it :-).]

-- 
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 Tuesday, 17 May 2011 04:28:11 UTC