in-use framebuffer handles are reused after context is re-created (when copying state from previous context)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. generate an FBO
2. create a new context, using the previous context as share_context
3. generate an FBO - the FBO ID will be the same as that above

When creating a new context the GL state of the previous context should be 
copied completely, including the allocated FBOs.

Context.cpp shows that mResourceManager is being copied, but the FBO handles 
seem to be managed by the mFramebufferHandleAllocator. I wonder if the other 
'Allocator' members should also be copied?

>git rev-parse HEAD
a6d110e2811b3d2e5827ba31669950e09a0d4305

On Windows 8

Original issue reported on code.google.com by cech...@gmail.com on 22 Apr 2015 at 3:06

[GoogleCodeExporter]

Is this a bug? Framebuffers are not shared objects, meaning each context has 
its own list of separate, unshared framebuffers. See Appendix D of the ES3 spec.

Original comment by jmad...@chromium.org on 22 Apr 2015 at 12:51

[GoogleCodeExporter]

I cant speak for the spec but it seems unusual - eglCreateContext is used by 
some context management libraries (e.g., GLFW) with the expectation that the 
contexts resources will be shared (this is the only way to switch between video 
modes)

On reading the specs, I remain confused. The OpenGL ES 2 spec (which it is my 
understanding is the most relevant?) reads: 

    One way to avoid this undefined behavior is to use GenFramebuffers for all framebuffer object names. Framebuffer objects with names returned by genFramebuffers in one context will never be shared with framebuffer objects whose names were returned by GenFramebuffers in another context

To me this indicates that there is a bug - I am personally using 
GenFramebuffers in my application and the names are indeed conflicting between 
contexts.

I wonder though why renderbuffer objects would be explicitly shared and 
framebuffer objects not? That seems to make the context sharing functionality 
/almost/ yet not quite useful... 

Original comment by cech...@gmail.com on 22 Apr 2015 at 2:42

[GoogleCodeExporter]

Hey cechner, can you confirm that GLFW relies on FBOs to be shared?

To help clarify: if the spec says something is undefined (as the GLES2 spec 
does in Appendix C for FBO sharing) that means ANGLE gets to choose. Since FBOs 
aren't shared in GLES3, it makes sense to never share them in 2 if we get the 
choice. So it doesn't seem like there's a bug here -- but if GLFW runs on GLES2 
and expects FBOs to be shared it's relying on undefined behaviour, which is a 
bug. I'm happy to help explain the spec in this aspect.

Original comment by jmad...@chromium.org on 22 Apr 2015 at 2:54

• Changed state: WontFix

[GoogleCodeExporter]

Oh yes, about GenFramebuffers - it's a bit hard to visualize without seeing 
your code. I think what the spec is suggesting is that instead of using 
BindFramebuffer(###) to create a Framebuffer, use GenFramebuffers, then it's up 
to you to manage your Context such that you are using the right FBO. I agree 
the spec is not very helpful here.

Original comment by jmad...@chromium.org on 22 Apr 2015 at 2:59

[GoogleCodeExporter]

Hi, thanks for the quick response. I agree that this is probably not a bug, 
upon reading the spec more closely. It is a shame, as it makes context sharing 
less useful but the workaround is quite simple (just create separate FBOs for 
each context)

Regarding code - I didnt post anything because my work is through a wrapper 
library I wrote. But you can see my workaround here 
https://github.com/seshbot/glpp/commit/dc65b33e5e26e07b33c0afc1db1d17691541381c 
(just deleting all FBOs when context is recreated - I was previously relying on 
each FBO reloading itself independently but they were stepping on each others 
toes.  Deleting them all at once fixes this)

Thanks again

Original comment by cech...@gmail.com on 23 Apr 2015 at 12:00

[GoogleCodeExporter]

also regarding GLFW - it does not actually rely on FBOs being shared, I was 
wrong about that. It is more that the help I could find regarding changing 
video modes did not mention that FBOs needed to be recreated, so I assumed that 
they did not need to be

Original comment by cech...@gmail.com on 23 Apr 2015 at 4:51