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

Re: exposing CANVAS or something like it to Web Workers

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 14 May 2012 16:42:03 -0700
Message-ID: <CA+c2ei-kGawrfYUA14c7NfXjO5iUpFtymwSbjTz_ZU=ObV_VcQ@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Anne van Kesteren <annevk@annevk.nl>, Gregg Tavares (勤) <gman@google.com>, Web Applications Working Group WG <public-webapps@w3.org>
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.


/ Jonas
Received on Monday, 14 May 2012 23:43:04 UTC

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