Re: exposing CANVAS or something like it to Web Workers

On Wed, May 16, 2012 at 12:30 PM, Gregg Tavares (勤) <gman@google.com> wrote:
> 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

This alternative seems like the one that can be moved forward most
easily, since essentially all of the changes would be within the WebGL
spec.

 - Extend the spec to support context sharing. (Each
WebGLRenderingContext points to an opaque WebGLContextGroup object.)
 - Define structured cloning semantics for WebGLContextGroup.
 - Add a constructor or factory method to WebGLRenderingContext
allowing creation with a WebGLContextGroup. Contexts created in this
manner would have no back buffer by default. (FBOs could still be used
to do rendering with the context.)
 - Allow some or all of the WebGLObject types (textures, etc.) to be
either copied during structured cloning or transferred.

Then the worker can at least upload textures to the GPU completely
asynchronously from the main thread, and inform the main thread via
postMessage when they have finished uploading. That seems to be a
tractable first step and one that would already have immediate
benefits for developers.

-Ken


> *) 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:43:20 UTC