I wonder, if FBOs can be shared between contexts via wglShareLists. The specifications are a bit vague about it. EXT_framebuffer_object says:
Issue (76) Currently framebuffer objects are shared, should we make them not shared across contexts?
RESOLUTION: yes, framebuffers are shared like display lists and textures are shared.
ARB_framebuffer_object has no such paragraph and only mentions the sharing of renderbuffers explicitly.
But GL3.0 specs (which moved ARB_fbo into core) say:
Appendix D, p.402
…
Framebuffer and vertex array objects are not shared.
I’m writing against GL2.1 and I’m currently using only the EXT_fbo functions. So, which behaviour should I rely on?
If you are using GL 2.1 and EXT_fbo, then the FBO ID is shared.
If you are using GL 3.0 (forward), then I think it doesn’t matter if you use core FBO or ARB_fbo. The FBO ID is not shared.
In any case, a FBO is not important. The important is the texture or renderbuffer.
Well, might change your design a bit having to refactor your FBO per-context or whatever…
Looks like the 3.2 spec got a bit of spit and polish w.r.t. sharing, multiple contexts and the addition of sync objects. Seems to be much better multi-threading opportunities here, what with the new rules on sharing, updates, etc.
Since the sharing of renderbuffers and textures is still allowed, forbidding sharing of FBOs won’t gain much multithreading opportunities. Concurrent access to shared resources must still be covered.
I guess, the reasoning not to share FBOs is
a) they are “just” container objects, so they won’t eat up much resources anyway
b) they carry render-state information with them (drawbuffer/readbuffer setting). This would open a door to “render state propagation” between contexts, which is not what “sharing lists” was intended for.
I think, it is safer to rely on “do not share FBOs”. It has less problems and is forward compatible to 3.x