[whatwg] WebWorkers and images
Glenn Maynard
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
> suspended.
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
>> scene.
>
> 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
> memcpy.
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
concurrency).
--
Glenn Maynard
More information about the whatwg
mailing list