Re: exposing CANVAS or something like it to Web Workers

On Wed, May 16, 2012 at 12:42 PM, Kenneth Russell <kbr@google.com> wrote:

> 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.
>

That problem I have with this path is the cons mentioned above. It's a dead
end.

With real contexts you can do this

    webglcontext1.texImage2D(..., webglcontext2.canvas);

and this

    context2d.drawImage(webgl.canvas, ...)

But with a context created with new WebGLRenderingContext you can't do
anything like that because size of the backbuffer is not defined.
Eventually we'll want to support operation like that and we'll likely end
up with something like DrawingSurface or CanvasSurface or OffscreenCanvas.
At that point this ability to go "new WebGLRenderingContext" will just be
left over cruft.

Also we'll have to define how to addEventListner for WebGLRenderContext for
listening for lost context or for async context creation (yea, less
important on workers). That stuff is currently not on
WebGLRenderingContext. It seems like it should stay off if it.








>
> -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:
> >
> > . ???
> >
> >
> >
> >
>