[whatwg] WebWorkers and images
glenn at zewt.org
Thu Jan 13 15:38:58 PST 2011
On Thu, Jan 13, 2011 at 5:21 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> The second one is actually really really hard to do with setTimeout.
> Especially if you have UI events that need more than one trip through the
> event loop to do their thing.
In simple event systems that's mostly a matter of running the event
loop until nothing more happens, but I'm sure it's very complicated
with a production browser.
Ultimately, the right solution is to do all work like this in workers
anyway--but it'll be a long time, if ever, before we can fully do so
(eg. real canvas and WebGL access).
>> You don't need any trickery to get the latter
> I'm not sure what you mean by "trickery" here.
Timing threads to achieve smaller timers than 10ms on Windows, as you
mentioned Chrome does.
> I oversimplified the spec a bit, for simplicity, because the main issue is
> in fact the clamped timers and what to clamp to and how to do it. The spec
> specifies a heuristic to use in just such a way, in fact. I suggest you
> just read it if you're interested in the details....
I have; it allows UAs to clamp longer, but doesn't permit browsers to
allow nested timeouts of less than 4ms, even if they design a
heuristic that allows doing so safely.
> timeouts in workers are... weird as currently specced. Not only do they
> have the 4ms floor for nested timeouts, but they're not specced in terms of
> wall-clock time but rather in terms of time during which the worker is not
That's odd, indeed. This seems likely to force people who want
30-second timers into setting 1-second timers and checking the time
manually. That's (mildly) wasteful, and easy to get wrong if the
system clock changes (though I guess browsers don't actually handle
that well, either).
>> For code that renders an entire scene at a time and displays it (most
>> typical double-buffered OpenGL-like rendering), this might be useful,
>> but I'm not sure it helps here. He's incrementally rendering the
>> result, so he needs to keep a copy of it to continue rendering the
> Who's incrementally rendering what?
http://skypher.com/SkyLined/demo/FractalZoomer/Mandel.html, linked earlier.
> The idea with the forgets approach would be that you have an imagedata
> object. You pass it to the worker, the worker modifies it and passes it
> back. The only constraint is that you can't touch the object while the
> worker is modifying it. That seems like a pretty common use case. Are we
> talking about some other use case here?
I agree that's probably useful, and frame-by-frame rendering is much
more common than incremental rendering.
>> I suspect there's something simpler going on here, though--as you
>> said, copying a 10 MB buffer really should be very quick.
> It's really not that quick, actually. First, you have to allocate a new
> 10MB buffer. Then you have to memcpy into it. Then you have to free it at
> some point. I just wrote a simple test C program that has a single 10MB
> array initialized and then in a loop allocates a 10MB array, memcpys into
> it, and then frees the 10MB allocation it just made. It takes about 5ms per
> loop iteration to run on my system (fairly high-end laptop that was new in
> July 2010). The time is split about 50-50 between the allocation and the
It might be possible to optimize the allocation further, but even
2.5ms is worth optimizing out. If you're trying to maintain 60 FPS
(16.6ms per frame), that's 15% of your total available time (ignoring
More information about the whatwg