[whatwg] WebWorkers and images

[Glenn Maynard]

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