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

Eric Anholt eric at anholt.net
Mon Nov 14 08:25:06 PST 2011


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20111114/a66c950e/attachment-0001.pgp>


More information about the mesa-dev mailing list