- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 14 May 2012 16:42:03 -0700
- 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. Agreed! / Jonas
Received on Monday, 14 May 2012 23:43:04 UTC