Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I believe your problem has to do with the fact that FBOs themselves cannot be shared across contexts. What you can, however, do is share the attached data stores (renderbuffers, textures, etc.).</p> <p>It really boils down to the fact that FBOs are little more than a pretty front-end to manage collections of read/draw buffers, the FBOs themselves are not actually a sharable resource. In fact, despite the name, they are not even Buffer Objects as far as the rest of the API is concerned; have you ever wondered why you do not use <code>glBufferData (...)</code>, etc. on them? :)</p> <blockquote> <h3>Critically Important Point:</h3> <blockquote> <p><strong>FrameBuffer</strong> <em>Objects</em> are not <strong>Buffer Objects</strong>; they contain no data stores; they only manage state for attachment points and provide an interface for validation and binding semantics.</p> <blockquote> <p>This is why they cannot be shared, the same way that <strong>Vertex Array Objects</strong> cannot be shared, but their constituent <strong>Vertex Buffer Objects</strong> can.</p> </blockquote> </blockquote> </blockquote> <p><strong>The takeaway message here is:</strong> </p> <ul> <li>If it does not store data, it is generally not a sharable resource.</li> </ul> <p>The solution you will have to pursue will involve using the renderbuffers and textures that are attached to your FBO. Provided you do not do anything crazy like try and render in both contexts at once, sharing these resources should not present too much trouble. It could get really ugly if you started trying to read from the renderbuffer or texture while the other context is drawing into it, so do not do this :P <hr> Due to the following language in the OpenGL specification, you will probably have to detach the texture before using it in your other context:</p> <h3><a href="http://www.opengl.org/registry/doc/glspec32.core.20091207.pdf" rel="nofollow">OpenGL 3.2 (Core Profile)</a> - 4.4.3 Feedback Loops Between Textures and the Framebuffer - pp. 230:</h3> <blockquote> <p>A feedback loop may exist when a texture object is used as both the source and destination of a GL operation. When a feedback loop exists, undefined behavior results. This section describes rendering feedback loops (see section 3.8.9) and texture copying feedback loops (see section 3.8.2) in more detail.</p> </blockquote> <p>To put this bluntly, your white textures could be the result of feedback loops (OpenGL did not give this situation a name in versions of the spec. prior to 3.1, so proper discussion of "feedback loops" will be found in 3.1+ literature only). Because this invokes undefined behavior it will behave differently between vendors. Detaching will eliminate the source of undefined behavior and you should be good to go.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload