[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Issues with sharing resources across contexts

On Fri, Aug 24, 2012 at 7:04 PM, Gregg Tavares (社用) <gman@google.com> wrote:
Vladimir above mentioned the case of rendering to a canvas from a worker. I think we should look at their proposal once they make it public. But that specific use case is orthogonal to the issues of shared resources among multiple canvases and shared resources with workers.

So, back to the shared resources issues. Others have suggested passing the objects. So,

   texture: someTexture,

would pass ownership of the WebGLTexture referenced by 'someTexture' to the worker. At that point using 'someTexture' in the main page would start generating INVALID_OPERATION just like a WebGLTexture created in another context does now.

That sounds simpler. Basically you dont' have to designate which objects are shared. You can just only use them in one thread (main or worker) at a time.
I think the "shared resources between canvasii" idea is superfluos. The only reason you want a second canvas is in order to display something. If you just want to display something, you can take all the complexity entirely out of that so you don't have to mangle it together with cross thread/process sharing and just do that, display something. We already know how to make off-screen rendering with FBOs. The compositor already uses textures to composit the page, and texturing is used in the compositor to avoid readbacks for hardware accelerated canvasii. In order to render a second view of our data we'd just like to be able to bind a "surface", emit our drawing commands and then be done. The canvas (singular, bound to a single context) is so far the only "front" buffer we have. But given that it's all texturing underneath, there isn't a logical reason why such an exceedingly simple idea as using as many "front" surfaces as you want bound to an FBO should be in any way be impacted by complex things like resource sharing.