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

[Eric Anholt]

On Mon, 14 Nov 2011 09:29:48 -0700, Brian Paul <brianp at vmware.com> wrote:
> 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.

Yeah, instead of getting/putting pixels at a time.  Not being able to
store alpha even though it claims to have visuals with alpha is really
rude -- at least this way the alpha would be correct within a single app.

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

100% agreement on spans.  I was neutral on RB wrapping before, but if it
just hasn't been working, let's drop the idea.
-------------- 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/76cf2b59/attachment.pgp>