[whatwg] WebWorkers and images

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.  At this point the only browser that does for repeated 
timeouts is Chrome, which allows 4ms.  Various browsers allow timeouts 
up to some small level of nesting to run arbitrarily quickly; that 
started because it happens to make JSBench run faster due to the broken 
way that benchmark is constructed.

In any case, to implement the 4ms thing on Windows Chrome has to have a 
dedicated thread polling the multimedia timer, which is a huge PITA in 
terms of things like wakeups and battery life... And for what it's worth 
on my Mac they don't manage to hit the 4ms thing either; they get closer 
to 4.7ms on average, though I haven't looked at the distribution.  And 
if I lower Gecko's clamp to 4ms, I get a similar 4.7ms average on Mac, 
so that might just be an OS limitation too.

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).

> Why was the>= 10ms minimum timer duration spec'ed this way ?

The current spec draft says the floor is 4ms.

>> Note that if your computational work is entirely working with
>> ImageData, you can send the ImageData to a thread.  It's limiting (you
>> can't blit images to the canvas that way, since you don't have the
>> Canvas interface), but it may be enough for your case.
>
> I've tried once to improve a full-screen animation like that, and found that the cost of passing the data back and forth to the worker is so high

A full-screen on my screen would mean a 9.2MB imagedata.  So depending 
on how often you're trying to pass it back and forth, just creating the 
copies could be pretty expensive, yes.  If it's being round-tripped 
through a string or something it would be even worse.

It would be interesting to have an API that allows passing an imagedata 
object (not a copy) to a worker.  Such an API would have to make the 
data disappear on the caller's side.  That could be implemented 
reasonably efficiently using shared memory (either directly with threads 
or using shared memory segments with processes).

That said, I would be interested in seeing your testcase for this; in my 
experience bottlenecks in situations like this can be in ... surprising 
places.

> That was passing the objects serialized as text messages.

And serializing in JS?  Yeah, that would be pretty slow!

> Perhaps with structured clones, the situation may have been improved a bit.

It should have, even with the copying that probably happens now.  Worth 
retesting.

> But I think that the workers desperately need a mechanism that permitted to pass objects *quickly*, and *quickly* most likely means by reference not by copy.

Then it needs to be something that passes the object and _forgets_ it on 
the caller side.

> To preserve shared-nothingness, the passed object (and the object's children) could be made unreachable (somehow, don't ask me)

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.

-Boris

Received on Thursday, 13 January 2011 06:41:26 UTC