2009/4/3 Michel Dänzer <mic...@daenzer.net>: > On Thu, 2009-04-02 at 16:28 -0400, Kristian Høgsberg wrote: >> >> Ok, yes, glDrawBuffer(GL_FRONT) has to work, but always allocating an >> extra color buffer that most apps won't ever use is not a good use of >> memory. So what about this: for a double buffered visual, the dri >> driver doesn't ask for the front at all, which the loader should >> handle just fine. Then if the app wants to draw to the front buffer, >> it will call getbuffers, but asking for the front buffer and not the >> back buffer, that is, identical to the request it would issue for a >> single buffered visual. And then it just works, since if the drawable >> is a window, we'll ask for the fake front instead and pass that to the >> driver. > > One problem with this is that the server side DRI2GetBuffers() currently > only re-allocates buffers from the driver if the drawable size changes; > it doesn't check if the buffer attachments or even the number of buffers > requested change.
Yeah, the server side code may need to reviewed to make sure it allocates any buffers it doesn't already have for the current size. > Even assuming that can be solved, don't we still need both buffers for > things like glCopyPixels with glReadBuffer != glDrawBuffer? Yeah, true. But we'll just ask for both at the time the client sets the front buffer as either draw or read buffer. And it makes the logic more intuitive: if the client ever asks for the front buffer for a window, give it the fake front buffer. The choice to only ask for the back buffer for the normal, double buffered case is then just a dri driver side optimization. cheers, Kristian ------------------------------------------------------------------------------ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
