-----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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknVUecACgkQX1gOwKyEAw9JkACcCMu9yPfud6022ZTOTviLD2r7 8jsAn35jeuY1opVeeoYdCFADeEbjChwo =G8Ty -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
