Re: exposing CANVAS or something like it to Web Workers

On Mon, May 14, 2012 at 6:42 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> If/when we do this, I think it should be done in such a way that the
> main window can't access the canvas object at all. Similar to what
> happens when an ArrayBuffer is transferred to a Worker using
> structured cloning. Once a canvas is transferred to a Worker, any
> access to it should throw or return null/0/"".


Sort of.  You want to disable the methods on Canvas--toDataURL, toBlob and
getContext--but you don't want to disable inherited methods (you should
still be able to access eg. parentNode).  I think handling this on a
method-by-method basis is fine, since there aren't many of them--just those
three, I think.

I still don't have much intuition about how to do this, but another
thought: assuming you create a context in the worker which is attached to
the canvas, you need to be able to create new contexts in the future if the
worker dies, since workers can be killed by the browser at any time.  A
mechanism that says "you can create a worker-context for a canvas, but then
the canvas element is locked to that worker" isn't good enough (but it's
fine to say "you can only have one worker associated with a canvas at a
time").

If you want to transfer
> pixel data to the main thread, it seems less racy to do that by
> getting the pixel data in the Worker which owns the canvas and then
> transfer that to the main thread using postMessage.
>

Right.


>  > This would also require some
> > equivalent to requestAnimationFrame in the worker thread.
>
> Agreed!
>

A tricky bit: you need to know which element to sync to, so the browser
knows which monitor's vsync to use.  According to [1] only WebKit's
requestAnimationFrame actually takes an element.  (That's surprising; this
seems obvious.  Are multi-monitor systems always vsync-locked to each
other, which would make this not matter?)  I mention this because this
method would need to accept a context in lieu of an element (assuming
whatever mechanism we land on it results in having a WebGLContext in the
worker but no HTMLCanvasElement, whcih seems likely).

This in mind, it would be good if all Canvas context types had a common
base class, even if it's an empty interface.  The return value of
HTMLCanvasElement.getContext could be changed to it, instead of object.

[1] https://developer.mozilla.org/en/DOM/window.requestAnimationFrame

-- 
Glenn Maynard