On Mon, 14 Nov 2011 09:29:48 -0700, Brian Paul <bri...@vmware.com> wrote:
> On 11/14/2011 09:25 AM, Eric Anholt wrote:
> > On Fri, 11 Nov 2011 13:45:15 -0700, Brian Paul<bri...@vmware.com> wrote:
> >> On 11/11/2011 09:34 AM, Eric Anholt wrote:
> >>> On Thu, 10 Nov 2011 18:01:47 -0700, Brian Paul<bri...@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.
pgp7P4GLc2qw3.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
