[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Issues with sharing resources across contexts
I think it would be important to structure this around use-cases, why do we want more contexts and what will we do with them?
1) Putting multiple canvases on one page showing the same underlying data in different ways. For instance, multiple viewports of a 3d editor. I know some will object this is a job for gl.viewport, but it is not. Those viewport could be arranged in a UI by being their own dragable/resizable etc. "widgets". Similar use-cases can be found in many games.
2) Operating one context from multiple processes (i.e. web-workers) where for instance one web-worker would tessellate and upload to a VBO while the main process would do other things.
I can't think outright of other use-cases, but I'm sure there are some more structurally different.
Regarding the need to show the same underlaying data in multiple views, there are different solutions to this:
a) create two gl contexts, have them share resources. This introduces the aforementioned synchronization issues.
b) Operate one context with the ability to target multiple front buffers. For instance, kind of like FBOs, except the rendering is not "off screen" but you'd attach say, a canvas as rendertarget.
Regarding multi-process use of one context: If we write code like this at the moment we synchronize over the webworkers synchronization feature of buffers, where one buffer is held by only one worker at a time. Any kind of multi-threaded working will always need to properly synchronize to work, so I don't feel like making it possible to pass resources to workers which means the "own" them for the duration of their work is much different than passing a buffer to a worker, which means the same. It might be a bit more convenient to operate the API in the worker directly instead of sending around buffers, but probably not all that much. One added benefit of the resource is that if you emit a command to the buffer that would cause a finishing wait, that delay could be encapsulated in the worker rather than holding up the main thread.
On Tue, Jul 17, 2012 at 3:03 AM, Gregg Tavares (社用) <firstname.lastname@example.org>
I agree that solution would work for 2+ contexts in a single webpage since webpages are single threaded. Is that enough for now? Do we care about WebWorkers where that solution will no longer be enough?
Lemme throw out some ideas. They probably suck but maybe they'll jog some others.
What if a resource could only be used in 1 context at a time and you had to transfer ownership to use it another context? That might solve this issue as well. Would that be too restrictive? What if an object could be used in any context but state only set in the context that "owns" it? Not sure that would help. In the case above it would mean any context could call UseProgram but only the context that owns it could call AttachShaders and LinkProgram since those change state. Of course that wouldn't solve every issue because UseProgram requires the results of LinkProgram.
I'm just throwing that out there. The idea is probably not workable but it would be nice to try to design an WebGL API for WebWorkers that didn't have the ambiguity that OpenGL has as far as execution order. Whatever that solution is might also work for 2 contexts in the same page.