2017-01-18 18:23 GMT+08:00 Józef Kucia <joseph.ku...@gmail.com>: > On Wed, Jan 18, 2017 at 2:25 AM, Boyan Ding <boyan.j.d...@gmail.com> wrote: >> I don't think I find that. The only place in state tracker where >> _mesa_add_renderbuffer is called is st_framebuffer_create and only one >> of the front and back buffers is allocated based on the default >> behavior. When update_framebuffer_state() in state tracker is called >> after draw buffer changes to front, state tracker will find it refers >> to a null renderbuffer and remove it afterwards. > > Buffers are allocated on demand in st_DrawBuffers() and > st_ReadBuffer(). The issue is though a bit different. A single GL > context is used with two windows (drawables). > glDrawBuffer/glDrawBuffers() is called when the first window is > current, then after glXMakeCurrent() with the second window a new > st_framebuffer is created but GL_FRONT renderbuffer is never allocated > for the newly created st_framebuffer.
Yeah, you're right. I overlooked the on demand allocation, which turns out to be the key to the problem. After calling _mesa_drawbuffers in main, renderbuffers will be allocated on demand in state tracker with DrawBuffers driver hook. But there is one path in main where DrawBuffers hook isn't invoked after calling _mesa_drawbuffers -- update_framebuffer in main/framebuffer.c. Adding it fixes the problem. Before sending out the patch, I'm just wonder if putting _mesa_drawbuffers and DrawBuffers hook invocation into a function will be a better style. Because there is a function _mesa_update_draw_buffers, which is _mesa_drawbuffers without DrawBuffers hook used when switching contexts. _mesa_drawbuffers and DrawBuffers hook invocation can also fit into a function used to reconfigure draw buffers for window system framebuffers. Regards, Boyan Ding _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
