On Thu, Apr 2, 2009 at 8:01 PM, Ian Romanick <i...@freedesktop.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 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. It wont be fast, but we're mostly concerned with correctnes >> for front buffer rendering anyway. > > Almost. I believe a legal usage case is to call glXWaitX, then call > glDrawBuffer. Since the glXWaitX happens before the fake front buffer > is created, the fake front buffer will be empty. I guess we could do an > implicit glXWaitX in the loader whenever a GetBuffers call requests a > fake front buffer.
Yup, sounds fine. cheers, Kristian ------------------------------------------------------------------------------ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
