On Mon, 8 Jul 2002, Brian Paul wrote: > Graham Hay wrote: > > --- Leif Delgass <[EMAIL PROTECTED]> wrote: > > > >>On Sun, 7 Jul 2002, Brian Paul wrote: > >> > >> > >>>The notion of 'current read buffer' is more complicated than one would > >>>first expect. There are basically two situations in which you need to > >>>read from a color buffer: > >>> > >>>1. glRead/CopyPixels() and glAccum() > >>>2. blending/logicops/masking > >>> > >>>In the first case, the source buffer is whatever glReadBuffer() indicates. > >>>Furthermore, the source for the pixels may be a completely different > >>>window. > >> > >>>The glXMakeContextCurrent() and glXMakeCurrentRead() functions let you > >>>specify different drawables (windows) for reading and writing pixels. > >> > >>>That's > >>>why Mesa's swrast->Driver.SetReadBuffer() takes a GLframebuffer argument. > >>> > >>>In the second case, the source buffer is what glDrawBuffer() indicates. > >>>Mesa considers the second case to be the more common and usually keeps > >>>the "default read buffer" = "default draw buffer". > >>> > >>>So the basic idea is to read spans from whatever the > >>ctx->Driver.SetDrawBuffer() > >>>call indicates, until overridden by swrast->Driver.SetReadBuffer(). > >> > >>The problem is that the read buffer for these two cases can be different > >>at a given state, but swrast->Driver.ReadRGBASpan() and friends always > >>read from the buffer set by swrast->Driver.SetReadBuffer() (unless > >>SetReadBuffer hasn't been called, in which case the default read buffer is > >>GL_BACK_LEFT for a double-buffered visual and GL_FRONT_LEFT for a single > >>buffer visual). This is because the hardware driver doesn't know if these > >>functions are called by Mesa for the first or second case you mention. > > The driver should assume the second case. swrast->Driver.SetReadBuffer() > will get called for the first case, as needed.
I missed this comment before. If we assume the second case, we'd change the ReadBuffer (mmesa->readOffset in the driver) whenever ctx->Driver.SetDrawBuffer() is called, right? And you're saying that swrast->Driver.SetReadBuffer() will be called to change to the real ReadBuffer for glReadPixels, right? Would Mesa then call ctx->Driver.SetDrawBuffer() again to set the state back to ReadBuffer = DrawBuffer for software rendering? -- Leif Delgass http://www.retinalburn.net ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
