W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: exposing CANVAS or something like it to Web Workers

From: Charles Pritchard <chuck@jumis.com>
Date: Mon, 14 May 2012 17:10:16 -0700
Message-Id: <C6D690AA-4292-405D-9856-2A22A9C3217F@jumis.com>
Cc: Glenn Maynard <glenn@zewt.org>, Anne van Kesteren <annevk@annevk.nl>, "Gregg Tavares (勤)" <gman@google.com>, Web Applications Working Group WG <public-webapps@w3.org>
To: Jonas Sicking <jonas@sicking.cc>
On May 14, 2012, at 4:42 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Mon, May 14, 2012 at 3:28 PM, Glenn Maynard <glenn@zewt.org> wrote:
>> On Mon, May 14, 2012 at 3:01 PM, Gregg Tavares (勤) <gman@google.com> wrote:
>>> I'd like to work on exposing something like CANVAS to web workers.
>>> Ideally how over it works I'd like to be able to
>>> *) get a 2d context in a web worker
>> I'd recommend not trying to tackle 2d and 3d contexts at once, and only
>> worrying about WebGL to start.
>> Another issue: rendering in a worker thread onto a canvas which is displayed
>> in the main thread.  This needs to be solved in a way that doesn't cause the
>> asynchronous nature of what's happening to be visible to scripts.  toDataURL
>> and toBlob would probably need to be prohibited on the canvas element.  I'm
>> not sure what the actual API would look like.
> 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/"". 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.
>> This would also require some
>> equivalent to requestAnimationFrame in the worker thread.
> Agreed!
> / Jonas

I'm a bit lost-- wouldn't we just postMessage from the document over to the web worker when we want a refresh?

I agree that we ought to be transferring pixel data not Canvas contexts; with the possible exception of CSS context.

We could just create new canvas instances inside the worker thread. I'd still prefer to clone CanvasPattern as a means of transferring paint over to the worker, though sending pixel data would work too.

I heard Picture come up-- it seems like that object might have additional semantics for high resolution alternatives that may need to be considered.

Received on Tuesday, 15 May 2012 00:10:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:34 UTC