[whatwg] WebWorkers and images

[Glenn Maynard]

On Thu, Jan 13, 2011 at 9:41 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> 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.

Well, there are two very separate use cases competing here:

- trying to actually get very short, accurate timers, and
- using timers simply to return to the browser, run any pending UI
events, and then immediately start work again with no additional
delay.

You don't need any trickery to get the latter, and in my experience
that's far more often the goal with zero-second timeouts.

>> Why was the>= 10ms minimum timer duration spec'ed this way ?
>
> The current spec draft says the floor is 4ms.

I strongly disagree with this.  Browsers should be allowed to permit
0ms "return, run events then run this code immediately" timers.  It
takes some heuristics to do this safely, to prevent code which
(usually accidentally) assumes a minimum delay from busy looping, but
browsers should be free to attempt such a heuristic, not required by
spec to clamp to 4ms.

Non-looping 0ms timers are common, to run code when the current call
finishes.  It's unfortunate that they're all forced to have an
arbitrary delay, and the spec should permit browsers to do better if
they're able.

Timeouts in workers shouldn't require this, either, since there's no
legacy code to worry about.

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

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.

I suspect there's something simpler going on here, though--as you
said, copying a 10 MB buffer really should be very quick.

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

I think there's also another problem: he's drawing the image, and
rendering the image incrementally as he goes.  To do that from a
worker, you'd need to keep sending the ImageData in a message to the
UI thread to display it.

That leads to a problem: how fast do you send it?  postMessage doesn't
wait for messages to be received; if the worker doesn't know that the
UI thread has actually received and processed the message, it won't
know whether it should send a new message yet.  If it simply sends
messages periodically, it may send them faster than the UI thread is
taking them, queuing up a bunch of messages containing huge payloads.

And there's trouble there: there's no way for the worker thread to
receive a "got your message, ready for the next one" message, unless
it returns to caller to allow those events to be delivered.

This seems like another important class of use cases for the
"synchronously handling events" thread on webapps.

-- 
Glenn Maynard