-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kristian Høgsberg wrote: > 2009/4/2 Ian Romanick <i...@freedesktop.org>: >> Kristian Høgsberg wrote: >>> color_rb[0] should always correspond to __DRI_BUFFER_FRONT_LEFT so >>> GLX_tfp works. And uhm, I'm just realizing that we don't want the >>> fake front buffer for single buffered rendering to pixmaps (or >>> pbuffers), where we can render directly to the underlying pixmap. So >>> what I'm thinking is that we shouldn't ask for the fake frontbuffer in >>> the dri driver but handle it in the loader. The dri driver doesn't >>> know whether the drawable is a pixmap or a window, so it doesn't know >>> whether it should render the the real front or the fake front. >>> >>> So my suggestion is to handle this in glxdri2c:dri2GetBuffers(). If >>> the driver doesn't ask for a back buffer and we're rendering to a >>> window, ask the server for fake and real front buffers, store the real >>> front buffer data in the loader drawable private and pass the fake >> I think we always have to ask for the real and fake front buffers for >> windows. Other than that, those changes sound reasonable. > > 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.
I have another patch set almost ready for review. However, I have encountered a couple difficulties. It seems like the only place to do the fake front-buffer "substitution" is on the server. I don't see a way to easily determine on the loader whether a drawable is a window, a pixmap, or a pbuffer. On the server, DRI2GetBuffers is, for lack of a better term, a really big hammer. It will always create and destroy everything passed in. This has an unpleasant side effect: We can't allocate just the fake front-buffer on-demand. Doing so would destroy the current back-buffer. Calling glDrawBuffer(GL_FRONT) can't cause the contents of the back-buffer to become lost. What we want to do is create a destroy buffers that are in the set requested by the client. If the client just asks for a front-buffer, we just create / destroy the (fake) front-buffer and leave the other buffers as-is. It seems preferable to put this logic in the DRI2 extension code, but with the existing driver CreateBuffers and DestroyBuffers interfaces, it would have to go in the driver. Every driver. Doing this isn't quite clean either. The driver still have to allocate the fake front-buffer and the real front-buffer. I don't see way to do this without returning both to the DRI2 extension code. We could put logic in DRI2GetBuffers on the server that only returns the fake front-buffer if both exist, but... yuck. To be perfectly honest, CreateBuffers and DestroyBuffers aren't the interfaces that we want for this. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknah0EACgkQX1gOwKyEAw8OhwCfRzbj3u5zhhMO0wBOsNi1GXY1 pNgAniXi83PexmU1mvDbm+upQL8k2kCN =u9bE -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
