[whatwg] unexpected use of the CORS specification
Hi, a friend of mine just wrote an interesting blog post about "unshortening twitter URLs", see http://benno.id.au/blog/2009/11/08/urlunshortener . In it he proposes that url shorteners should be treated specially in browsers such that when you mouse over a shortened url, the browse knows to interpret them (i.e. follow the redirection) and shows you the long URL as a hint. I would support such an approach, since I have been annoyed more than once that shortened URLs don't tell me anything about the target. As part of this would be a requirement for URL shorteners to support CORS http://www.w3.org/TR/cors/, which browsers can then use to follow the redirection. Further, Benno suggests extending http://www.w3.org/TR/XMLHttpRequest/ with a property to disable following redirects automatically so as to be able to expose the redirection. I am not aware if somebody else has suggested these use cases for CORS and XMLHttpRequest before (this may not even be the right fora for it), but since these are so closely linked to what we do in HTML5, I thought it would be good to point it out. I would think that at minimum Anne knows what to do with it, since he is editor on both. Regards, Silvia.
Re: [whatwg] What is the purpose of timeupdate?
On Sat, Nov 7, 2009 at 7:21 PM, Justin Dolske wrote: > On 11/7/09 3:21 PM, Jonas Sicking wrote: > >> When timeupdate was added, the stated goal was actually as a battery >> saving feature for for example mobile devices. The idea was that the >> implementation could scale back how often it fired the event in order >> to save battery. >> >> Now that we have implementation experience, is timeupdate fulfilling >> this goal? If not, is it fulfilling any other goals making it worth >> keeping? > > FWIW, I felt that having Firefox's default video controls update their state > for every frame was excessive (and could lead to competing for the CPU with > the video itself). So, the controls basically ignore timeupdate events that > occur within .333 seconds of the last timeupdate position... Which leads to > having a bit of complication to deal with edge cases like having the video > end less than .333 seconds after the last timeupdate event (otherwise the UI > might look like stuck shortly before the end of the video). > > At least for my needs, having an event fire at ~3 Hz (and when special > things happen, like a seek or the video ending) would be somewhat simpler > and more efficient. I use timeupdate to register a callback that will update captions/subtitles. The alternative is to use the setInterval (or setTimeout) function which checks regularly whether your video's currentTime is still within your subtitle element. I think timeupdate is very useful, in particular since it is more accurate than checking currentTime. But I also think we need to add another mechanism to register events with the video/audio element that are triggered at the registered time (or within an interval). This would avoid constant polling for captions. At TPAC in the video breakout group we discussed a little how to re-introduce something like cue ranges in the context of captions in a declarative manner. We still need to make this more concrete, but it may be similar to the onenter and onleave events that the itextlist element has in https://wiki.mozilla.org/Accessibility/HTML5_captions_v2 . Cheers, Silvia.
Re: [whatwg] What is the purpose of timeupdate?
On 11/7/09 3:21 PM, Jonas Sicking wrote: When timeupdate was added, the stated goal was actually as a battery saving feature for for example mobile devices. The idea was that the implementation could scale back how often it fired the event in order to save battery. Now that we have implementation experience, is timeupdate fulfilling this goal? If not, is it fulfilling any other goals making it worth keeping? FWIW, I felt that having Firefox's default video controls update their state for every frame was excessive (and could lead to competing for the CPU with the video itself). So, the controls basically ignore timeupdate events that occur within .333 seconds of the last timeupdate position... Which leads to having a bit of complication to deal with edge cases like having the video end less than .333 seconds after the last timeupdate event (otherwise the UI might look like stuck shortly before the end of the video). At least for my needs, having an event fire at ~3 Hz (and when special things happen, like a seek or the video ending) would be somewhat simpler and more efficient. Justin
Re: [whatwg] What is the purpose of timeupdate?
On Fri, Nov 6, 2009 at 1:44 AM, Philip Jägenstedt wrote: > On Thu, 05 Nov 2009 21:11:15 +0100, Andrew Scherkus > wrote: > >> On Thu, Nov 5, 2009 at 6:10 AM, Brian Campbell < >> brian.p.campb...@dartmouth.edu> wrote: >> >>> On Nov 5, 2009, at 1:17 AM, Andrew Scherkus wrote: >>> >>> On Fri, Oct 30, 2009 at 10:18 PM, Brian Campbell < brian.p.campb...@dartmouth.edu> wrote: As a multimedia developer, I am wondering about the purpose of the timeupdate event on media elements. On first glance, it would appear that this event would be useful for synchronizing animations, bullets, captions, UI, and the like. The spec specifies a rate of 4 to 66 Hz for these events. The high end of this (30 or more Hz) is pretty reasonable for displaying things in sync with the video. The low end, however, 4 Hz, is far too slow for most types of synchronization; everything feels laggy at this frequency. From my testing on a two year old MacBook Pro, Firefox is giving me about 25 timeupdate events per second, while Safari and Chrome are giving me the bare minimum, of 4 timeupdate events per second. At 4 timeupdate events per second, it isn't all that useful. I can replace it with setInterval, at whatever rate I want, query the time, and get the synchronization I need, but that makes the timeupdate event seem to be redundant. At 25 timeupdate events per second, it is reasonably useful, and can be used to synchronize various things to the video. So, I'm wondering if there's a purpose for the timeupdate event that I'm missing. If it is intended for any sort of synchronization with the video, I think it should be improved to give better guarantees on the interval between updates, or just dropped from the spec; it's not useful enough in its current form. To improve it, the maximum interval between updates could be reduced to about 40 ms, or perhaps the interval could be made settable so the author could control how often they want to get the event. -- Brian I believe it's a convenience over using setTimeout/setInterval + polling to determine whether playback has progressed ie., for rendering your own playback progress bar. I've also seen it been used as a signal to copy frames into on Firefox, however if timeupdate frequency != fps of video you either miss frames or paint too much. I don't think timeupdate today is very useful for doing anything beyond a progress bar or other simple synchronized animations. >>> >>> Right. That's what I figured the point is; I just wanted to check to make >>> sure I wasn't missing something. >>> >>> As implemented by Safari and Chrome (which is the minimum rate allowed by >>> the spec), it's not really useful for that purpose, as 4 updates per >>> second >>> makes any sort of synchronization feel jerky and laggy. If it were done >>> at >>> the frame rate of the video, or perhaps with a minimum of 25 frames per >>> second, it would be much more useful. Even at a minimum of 15 frames per >>> second, you would still be able to get some sorts of useful >>> synchronization, >>> though animations synchronized wouldn't feel as smooth as they could. >>> >>> Would something like firing events for every frame rendered help you out? This would help also fix the over/under painting issue and improve synchronization. >>> >>> Yes, this would be considerably better than what is currently specced. >>> >>> -- Brian >>> >> >> I'll see if we can do something for WebKit based browsers, because today >> it >> literally is hardcoded to 250ms for all ports. >> >> http://trac.webkit.org/browser/trunk/WebCore/html/HTMLMediaElement.cpp#L1254 >> >> Maybe we'll end up firing events based on frame updates for video, and >> something arbitrary for audio (as it is today). >> >> Brian, since Firefox is doing what you proposed -- can you think of any >> other issues with its current implementation? What about for audio files? >> >> Thanks, >> Andrew > > We've considered firing it for each frame, but there is one problem. If > people expect that it fires once per frame they will probably write scripts > which do frame-based animations by moving things n pixels per frame or > similar. Some animations are just easier to do this way, so there's no > reason to think that people won't do it. This will break horribly if a > browser is ever forced to drop a frame, which is going to happen on slower > machines. In balance this may or may not be a risk worth taking. When timeupdate was added, the stated goal was actually as a battery saving feature for for example mobile devices. The idea was that the implementation could scale back how often it fired the event in order to save battery. Now that we have implementation experience, is timeupdate ful
Re: [whatwg] What is the purpose of timeupdate?
On Nov 6, 2009, at 5:52 PM, Simon Pieters wrote: On Fri, 06 Nov 2009 18:11:18 +0100, Brian Campbell > wrote: Brian, since Firefox is doing what you proposed -- can you think of any other issues with its current implementation? What about for audio files? The way Firefox works is fine for me. I haven't yet tested it with audio only, but something around 25 or 30 updates per second would work fine for all use cases that I have; 15 updates per second is about the minimum I'd consider useful for synchronizing one off events like bullets or slide transitions (this is for stuff where you want good, tight sync for stuff with high production values), and while animations would work at that rate, they'd be pretty jerky. What if you have a video with say one frame per second? Unless I'm mistaken Firefox will still fire timeupdate once per frame. (The spec says you have to fire at least every 250ms.) That's a fair point, though videos with frame rates that low are pretty rare. I suppose if you encoded something like a slideshow as a video, with a very low frame rate, you might get such an effect. Of course, if you're playing a video at that frame rate, I'm wondering what you would need to be synchronized at a higher frame rate; though if it has an audio track as well, you may be trying to synchronize against the audio. If this is something that we think is worth worrying about, then I'd advocate for just saying that timeupdate events should be fired approximately 30 times per second, perhaps with a minimum of 15 and a a maximum of 60 or so. For videos over 15 FPS, the browser could simply send one update per frame; for videos with a lower frame rate, the browser would have to generate intermediate timeupdate events to keep the interval reasonable. Or, the browser could just pick a rate in that range and send the events at that rate, without tying them to when the frames are displayed. I'd be fine with just having a reasonably consistent rate of 30 updates per second while the video is playing. -- Brian
Re: [whatwg] [WebWorkers] About the delegation example
Chris Jones wrote:
If I were writing a computationally-bound webapp, I would want an
interface like
[main thread]
SharedWorker.parallelMap(workerfn [, ...]])
[worker thread]
function workerfn(myThreadIndex, numberOfworkerfns [, ...]) {
// partition problem dataset [...] based on |myThreadIndex| and
|numberOfworkerfns|
// compute
}
On second thought, I think that worker semantics dictate that the
dataset partitioning decision should be made by [main thread] before the
workers are spawned. But I don't think this significantly changes the
API (move "// partition ..." into [main thread]).
Cheers,
Chris
Re: [whatwg] localStorage mutex - a solution?
Rob Ennals wrote: Missed out the important final qualifier. Here's take 3: "the user agent MUST NOT release the storage mutex between calls to local storage, except that the user agent MAY release the storage mutex on any API operation /other that a local storage oeration/" IMHO, this is actually worse than the current proposal of a global mutex :S. This proposal makes atomicity guarantees not only library-dependent, but browser-implementation-dependent. For example a = localStorage.x() jquery.foo() b = localStorage.y() If |jquery.foo()| were, say, parsing JSON or determining selector matching, it might involve "browser API calls" in some browser, and in others not. Worse, if |jquery.foo()| involves accessing browser-managed things like computed DOM attributes, then even in the *same* browser it might result in sometimes needing a "browser API call", and sometimes only needing a JS-only call. (Depending on DOM attribute cache status, if present.) This of course of depends on the definition of "browser API call", but I interpret this as approximately meaning "calling from JS to C++". These objections are in addition to those made by Jeremy Orlow concerning a script-managed, possibly cross-process mutex, which I also find unpleasant. Cheers, Chris
