Re: exposing CANVAS or something like it to Web Workers

So how to take this forward?

My #1 priority is to get WebGL in workers. Lots of developers have
expressed a need for this from decoding compressed textures in a worker to
offloading thousands of draw calls per frame to a worker. WebGL already
defines sharing mechanisms so at least for the WebGL case I don't need to
solve how to display anything back in the main worker. The worker can draw
to a texture. The main page can use that texture. WebGL/OpenGL already
define that relationship.

But, to get WebGL in a worker I need a way to get a WebGLRenderingContext
into a worker.

Some Ideas

**) Create context in main page, pass to worker*

Pros:

. No new APIs or objects.

Cons:

. Transfer is messy.

What happens to all the entry points and properties to the context object
left in the main page?
What happens to the "cavnas" parameter on the transferred context?
How do you synchronize the main page setting canvas.width or canvas.height
with the worker trying to render to it?


**) Create a context directly in a Worker (or anywhere for that matter)*

As in "var gl = new WebGLRenderingContext"

Pros:

. ???

Cons:

. requires defining how the backbuffer size is set.
   Maybe there is no backbuffer for a directly created
WebGLRenderingContext?
. if there is no backbuffer then using one of these contexts to draw into a
texture
  or 2d context is problematic


**) Create an offscreen canvas like object minus HTMLElement parts*
*
*
Pros:

. same or nearly the API as already exists for canvas
. flexible. getContext can return different kinds of context. Maybe only
"webgl" for now?

Cons:

. ???

Received on Wednesday, 16 May 2012 19:31:22 UTC