[Mesa-dev] [Bug 38312] Swrast doesn't really know whether a Framebuffer object is bound

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=38312

--- Comment #17 from Brian Paul <brian.e.paul at gmail.com> 2011-06-15 07:02:31 PDT ---
(In reply to comment #15)
> (In reply to comment #14)
> > Between the call to glBindFramebuffer() and
> > glGetIntegerv(GL_FRAMEBUFFER_BINDING) are you calling glXMakeCurrent()?
> 
> As far as I can see, no, we don't call glXMakeCurrent between these two points.

OK.


> > That
> > would change the context's framebuffer binding.  We might have that wrong,
> > actually...
> 
> Why would glXMakeCurrent change GL state?

glXMakeCurrent creates a binding between a rendering context and a surface for
drawing.  The surface (an X Window or GLXPixmaps) is internally represented by
an FBO.  Window system FBOs like that and user-created FBOs are pretty much the
same with only minor differences in how they're handled.  In any case, the
context has "current FBO" pointers that are set in glXMakeCurrent().  That's a
potential state change.

The GL_ARB/EXT_framebuffer_object extensions say that calling glXMakeCurrent()
should not change the current read/draw FBO bindings if the context is
currently pointing at user-created FBOs.  I needed to check Mesa to be sure
that we weren't inadvertently binding the X window FBO at in this situation. 
It looks like we're doing the right thing.  I just wrote a new piglit test to
verify this fact.

Anyway, I don't think this is the issue.  Perhaps you could sprinkle more
glGetIntegerv(GL_FRAMEBUFFER_BINDING, &x) calls between the glBindFramebuffer()
call and the failure point.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.