[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 10:30 AM, Florian Bösch <pyalot@gmail.com> wrote:
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,

worker.postMessage({
   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.


That's a really good idea!

if you could call

   gl.bindFramebuffer(gl.FRAMEBUFFER, someCanvas);

or similar that would mean sharing resources on the main page is not needed.

You'd still arguably need a way to mark a canvas as using WebGL although maybe it could happen automagically on bind. 

Would this work

var canvas1 = document.createElement("canvas");
var canvas2 = document.createElement("canvas");
var gl1 = canvas1.getContext("webgl");
var gl2 = canvas2.getContext("webgl");

//now both canvases are webgl canvases

// swap them just for fun
gl1.bindFramebuffer(gl.FRAMEBUFFER, canvas2);
gl2.bindFramebuffer(gl.FRAMEBUFFER, canvas1);

It seems like a little bit of a waste to have to create the second context just so the canvas is a WebGL canvas

Also, ti seems like overloading the meaning of bindFramebuffer might not be the best method since there all various operations you can do to currently bound framebuffer. So maybe it should be something like

gl.bindBackbuffer(canvas)

or

gl.bindCanvas(canvas)

and then like normal, calling 

gl.bindFramebuffer(gl.FRAMEBUFFER,null)

renders to the current backbuffer/canvas with all the limits that normally entails (can't call framebufferRenderbuffer or framebufrferTexture2D on it)