W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: exposing CANVAS or something like it to Web Workers

From: (wrong string) 勤 <gman@google.com>
Date: Wed, 16 May 2012 12:30:52 -0700
Message-ID: <CAKZ+BNoySNMipAafRHTwn-j1Mov6EhvKOs+9xkNL8XucPe89HQ@mail.gmail.com>
To: public-webapps@w3.org
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*


. No new APIs or objects.


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


. ???


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

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

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


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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:40 UTC