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

Re: [Public WebGL] Shared resources between contexts

There's an oddity in the ES spec: FBOs may or may not be shared.  This *might* mean that WebGL should never share WebGLFramebuffer.  This would take some research and we don't need to look too deeply into this right now; I'm just dropping a note here in case I forget about it.

On Sun, Jan 8, 2012 at 9:38 AM, Florian Bösch <pyalot@gmail.com> wrote:
On Sun, Jan 8, 2012 at 3:11 PM, Rehno Lindeque <rehno.lindeque@gmail.com> wrote:
Although I would prefer it if all contexts were simply shared by
default in order to have as little friction between engines /
libraries as possible, Glenn's proposal could be satisfactory for me.

I disagree that contexts should be shared by default. Resource sharing has real performance implications and it might create data inconsistencies. Separate pieces of code intended to be separate, should not have to explicitly state that they want to be separate. 

I wonder.  A primary reason resource sharing isn't the default in OpenGL is the way OpenGL resources work.  Applications in OpenGL can generate their own resource IDs.  While you're well-advised to use glGenTextures, you don't actually have to; you can make up your own IDs if you want.  This meant that sharing by default is impossible, because unrelated code that happens to both use OpenGL would step on each others' IDs.

That's not the case in WebGL, because resources are identified by objects, not integers.  Performance aside, sharing all resources would be perfectly safe.  The only way you can access a WebGL resource is by having a reference to it (or a query like getParameter(CURRENT_PROGRAM)); you really can't access them accidentally.

It's worth noting that there's a key difference between WebGL and OpenGL resource sharing: shared WebGL contexts will always be in the same thread, where OpenGL sharing can cross threads.  That could simplify implementations quite a lot and probably eliminate any performance impact, though this is more likely to help Direct3D-based implementations than ones which are a thin layer on top of real OpenGL (where they probably don't have enough control to take advantage of this).

Glenn Maynard