- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 25 Mar 2010 22:05:42 +0000 (UTC)
- To: Simon Pieters <simonp@opera.com>
- Cc: "public-html@w3.org" <public-html@w3.org>
On Wed, 10 Feb 2010, Simon Pieters wrote: > On Wed, 10 Feb 2010 03:45:26 +0100, Ian Hickson <ian@hixie.ch> wrote: > > On Mon, 1 Feb 2010, Simon Pieters wrote: > > > > > > We think it's better to always fire seeking, because we won't easily > > > be able to tell whether the new position is available. > > > > If you implement .buffered, surely you have all the information you > > need to know how readyState will change and whether the new position > > is available? Why would you not have that information? > > .buffered is not updated sync in the seek algorithm. Seeking in Opera > happens on a different thread. The seek algorithm requires to sync > decide whether to fire waiting and seeking (and get them in the right > order). We don't want to lock threads just this. It seems better to > always fire seeking when seeking and fire waiting later when the > playback is actually waiting. Is the new algorithm ok? (It doesn't quite change what you suggested, but it does it mostly all async.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 25 March 2010 22:06:11 UTC