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