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

[Brian Paul]

On 11/14/2011 09:25 AM, Eric Anholt wrote:
> On Fri, 11 Nov 2011 13:45:15 -0700, Brian Paul<brianp at vmware.com>  wrote:
>> 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.
>
> I wanted to use the alpha RB wrapper in swrast_dri.so, since it loses
> alpha values even though it claims to have an alpha channel on depth 24
> visuals, but it was just segfaulty last time I tried many months ago.
> It makes swrast_dri.so basically untestable for me.
>
> I'm surprised that both of these operate by constantly getting/putting
> values to shared storage.  Using actual private storage and putting data
> on swapbuffers would be nice and seems like it ought to be a lot faster.

Do you mean allocate another XImage for the front color buffer and 
call XPutImage() on glFlush()?  We could probably do that.

I'd like to get rid of all the renderbuffer wrapping stuff in core 
Mesa and the Get/PutSpan functions.

-Brian