On 13/01/2011, at 22:15, Boris Zbarsky wrote: > On 1/13/11 3:19 PM, Jorge wrote: >> On 13/01/2011, at 15:41, Boris Zbarsky wrote: >>> On 1/13/11 7:24 AM, Jorge wrote: >>>> Not too long ago, the browsers did allow timeouts of less than 10ms. >>> >>> Uh, no. Not too long ago browsers did not allow timeouts of less than >>> 10ms, ever. >> >> Last time I checked that in 2008, most Mac browsers had a +new Date() and a >> SetTimeout resolution of ~1ms down to ~ 0 ms > > 1) 2008 is not long ago. ;) > > 2) Don't mix up new Date and setTimeout.
But in order to measure such short setTimeout()s I needed to know whether +new Date() had enough resolution (*), in Oct 2008 it was in: All Macs, all browsers: 1ms. Win XP: Chrome, FF3, Safari: 1ms. IE, Opera, FF2 : 10ms. (*) http://jorgechamorro.com/cljs/024/ > 3) For setTimeout in particular, if the timeout is nested, browsers > clamp it from below and always have. For non-nesting timeouts > I'm not sure when Safari stopped clamping, if it ever did; Gecko > always did until mid-2009. > > 4) All of the above applies to browsers that had enough market share > that web compat was an issue. I haven't done testing of the > behavior in iCab, or links, or w3m or Amaya, because it's not > really relevant at this point. > >> Current Mac browsers behave ~ as you say, except Opera, that converts 0ms >> timeouts to 10ms, but for anything>= 1ms honors the ms parameter. > > Ah, indeed. I believe that Opera does this cross-platform. Thank you for > the correction. > >>> It looks like other browsers will be following suit on the 4ms thing >>> eventually for two reasons: the HTML5 spec specs it and there are lots of >>> bogus performance "benchmarks" that measure JavaScript execution speed >>> across timeouts. Now I suspect browsers won't actually _deliver_ decent >>> 4ms timers on Windows unless they jump through the hoops that Chrome does >>> with a polling thread; Windows just doesn't give you a sane way to deal >>> with times less than a tick (10ms on single-processor systems, 15ms on >>> multiprocessor ones). But they might be able to deliver something that >>> fires every 4ms on average (firing immediately sometimes and after 10-15ms >>> other times). >> >> If the goal is to protect the users from (badly written) programs that may >> drain the mobile's or laptop's battery, it's a bit sad to have to go down >> this route. > > Well, the problem is there are multiple somwhat-conflicting goals here: > > 1) Provide web pages with high-quality and high-resolution timers that they > can use to do various useful things. > > 2) Provide some protection against miscoded pages, especially accidentally > miscoded ones that are accidentally relying on the old timeout clamps. > > 3) Don't break web compat too much. > > (and maybe some others). Chrome started with a 1ms clamp for reason #1, then > moved to 4ms due to reasons 2 and 3.... Ok. Thanks for sharing. >>> It should have, even with the copying that probably happens now. Worth >>> retesting. >> >> Do current browsers implement the structured clones already ? > > Firefox 4 does, for postMessage to workers (but not yet to other windows; > known bug). I'm not sure about others. > >>> This is actually not all that bad for imagedata: just deallocate its >>> storage on the caller and make any access to the buffer throw. The key is >>> that you don't care that you have to copy things like the width/height; you >>> just don't want to copy the giant byte array. So you move the byte array, >>> and deny all access to its elements after that. Since the elements are >>> never pointed to by reference from JS, this works. >>> >>> For arbitrary objects this is harder, but could be done, actually. Gecko >>> already does something similar for Window objects when their origin >>> changes: you might still have a reference to the original object, but you >>> can no longer actually touch any of it. Under the hood, this is >>> implemented in a way that could be used for sending objects to a worker >>> too, I think. >> >> Good. So you think it might be feasible ? > > Yes. Cool. What's the right place to start lobbying for it :-) ? >> I think so too for objects composed only of data properties, but what about >> methods ? getters ? setters ? and prototypes ? > > "Maybe". It'd certainly take more work, and might start depending on exactly > how your VM is structured. Restricting to objects with null prototype and no > non-data properties has the slight problem that imagedata doesn't have a null > prototype. Hmm. I don't think there's hope for functions. -- Jorge.
