[whatwg] Counterproposal for canvas in workers

[Rik Cabanier]

On Sun, Oct 20, 2013 at 12:28 AM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Fri, Oct 18, 2013 at 6:50 AM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>> Extra methods on the canvas API:
>>
>> Promise setTaskScript(DOMString script); // can error be in promise?
>> Promise executeTask(DOMString id, dictionary json, boolean synchronized =
>> true); // Transferable elements allowed in dictionary
>>
>> Object that is active in the task:
>>
>> interface CanvasTask {
>>
>> HTMLCanvasElement createCanvas(unsigned long width, unsigned long height);
>> attribute Function onTask;
>>
>> }
>>
>> CanvasTask implements HTMLCanvasElement;
>>
>
> It looks like you intend CanvasTask to be the global object for the task
> script? So it's not a Worker and you don't get anything from
> WorkerGlobalScope? That's extremely limiting and also adds a lot of
> complexity by introducing a new kind of script global. You really would
> want to reuse workers here.
>

I have not really given this much thought. CanvasTask could be implemented
on top of a worker (like my naive polyfill)


> Also, making the HTMLCanvasElement API accessible from non-main threads is
> a big no-no. You can't let people do CanvasTask.document.window.whatever
> from non-main threads.
>

Yes, you can with my proposal.
The object that you get back with 'createCanvas' will be different under
the hood than the one you get in the main thread, but its *interface* will
be the same. Since all the calls can be marshalled to the main thread,
features like text and cors keep working. It should also be possible to use
images and canvaselement from the main thread since you don't have to
transfer their data.