Re: exposing CANVAS or something like it to Web Workers

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.  This
would also require some equivalent to requestAnimationFrame in the worker
thread.

*) download images in a web worker and the images with both 2d contexts and
> WebGL contexts


Don't forget to point people to the recent discussion on this, so the
conversation doesn't reboot:

https://www.khronos.org/webgl/public-mailing-list/archives/1205/msg00059.html

In summary, the idea is to provide a much more basic interface for images,
which would represent an image in an opaque, non-DOM way, to make it
implementable in workers; you'd retrieve it with a method on
HTMLImageElement after the image is completely available.  It'd be
structured clonable, to hand it to workers.  There should also be an XHR2
responseType mode to retrieve an object like this directly, to allow
loading images from workers (again without using the DOM), since workers
shouldn't need to rely on a helper in the UI thread just to load textures.

This seems like it would solve this sub-problem pretty well, at least.


On Mon, May 14, 2012 at 3:16 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> Have we gotten any further with use cases? See
>
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2010Mar/thread.html#msg144
> for an old use case thread that went nowhere. Or
>
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Feb/thread.html#msg274
> where you requested general DOM access which cannot be implemented
> everywhere.
>

The use case is being able to draw without blocking the UI thread.  WebGL,
like OpenGL, tries to be nonblocking by queuing draw operations, but it's
impossible to do this in all cases: as soon as you call any method that
returns data (eg. getError), WebGL has to synchronously flush the draw
queue.  This isn't as severe as synchronous XHR, but it may be done every
frame--a 10ms delay at 60Hz is going to have visible effects on the UI.

WebGL is also useful for computational tasks, which may perform much longer
drawing operations.  If you're doing this, it's even more important that it
not block the UI thread.

Compiling shaders can also take a long time for complex shaders.  Since
this is almost always followed by a synchronous call to check the result,
it's currently hard to load shaders without affecting the browser UI.

-- 
Glenn Maynard