On Mon, 8 Jul 2002, Leif Delgass wrote: > On Mon, 8 Jul 2002, Brian Paul wrote: > > 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?
I just tried making the driver set readOffset/Pitch = drawOffset/Pitch in SetDrawBuffer and it seems to work so far. If I put a glReadPixels into Graham's test program after the glDrawBuffer(GL_FRONT), the ReadBuffer is changed to GL_BACK before the ReadPixels and then changed back to GL_FRONT afterwards by Mesa! It looks to me like all the DRI drivers should be doing this. I understand why they don't, because it seems counter-intuitive. I'll have to do some more testing, but this just might solve the problem without any changes in Mesa. I think it's just a case of the hardware drivers not understanding Mesa's assumptions and behavior here. -- 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
