[Mesa-dev] [PATCH 2/2] xlib: set alpha to 0xff when mapping RGB pixmaps

[Brian Paul]

On 11/11/2011 09:34 AM, Eric Anholt wrote:
> On Thu, 10 Nov 2011 18:01:47 -0700, Brian Paul<brianp at vmware.com>  wrote:
>> Fixes a bunch of conform regressions.
>> ---
>>   src/mesa/drivers/x11/xm_buffer.c |   11 +++++++++++
>>   1 files changed, 11 insertions(+), 0 deletions(-)
>>
>> diff --git a/src/mesa/drivers/x11/xm_buffer.c b/src/mesa/drivers/x11/xm_buffer.c
>> index 6cf9f06..ea87b6d 100644
>> --- a/src/mesa/drivers/x11/xm_buffer.c
>> +++ b/src/mesa/drivers/x11/xm_buffer.c
>> @@ -477,6 +477,17 @@ xmesa_MapRenderbuffer(struct gl_context *ctx,
>>               return;
>>            }
>>
>> +         if (xrb->Base.Format == MESA_FORMAT_ARGB8888 ||
>> +             xrb->Base.Format == MESA_FORMAT_RGBA8888_REV) {
>> +            /* The original pixmap is RGB but we're returning an RGBA
>> +             * image buffer.  Fill in the A values with 0xff.
>> +             */
>> +            GLuint i, *p = (GLuint *) ximage->data;
>> +            for (i = 0; i<  w * h; i++) {
>> +               p[i] |= 0xff000000;
>> +            }
>> +         }
>> +
>
> If the actual storage only stores rgb, shouldn't we be claiming
> MESA_FORMAT_XRGB8888 or something?

That's a good point.  There's still some support for alpha 
renderbuffer wrappers in the driver.  So depending on how the buffer 
is accessed there might or might not be alpha values.  It's a mess 
that I plan to remove soon.

-brian