On Mon, 26 Jan 2004, Thomas Winischhofer wrote:

> Mark Vojkovich wrote:
> > On Mon, 26 Jan 2004, Thomas Winischhofer wrote:
> > 
> > 
> >>Can anyone explain the meaning of a8r8g8b8 "pure" alpha textures?
> > 
> > 
> >    It's probably a bug that XAA is letting those through.
> > a8r8g8b8 alpha masks mean one of two things:
> > 
> > 1) If componentAlpha is set, it's 4 alpha masks which act separately
> >    on the different components of the source.
> > 
> > 2) If componentAlpha is not set, you're supposed to just use the
> >    alpha portion.
> 
> OK, I see. I didn't analyze the code deeply enough. In my tests, the RGB 
> portion of the a8r8g8b8 formatted alpha texture was always zero. (Qt in 
> some way [indirectly] uses this to draw aa text, as does x11perf 
> -aaXXtest; stangely, I had this accelerated a while back WITHOUT 
> allowing a8r8g8b8 but ever since I installed Debian's experimental 
> packages with external libxrender and libxft the accelerated path wasn't 
> used. Despite that I recompiled these external libs against 4.3 headers.)
> 
> I do now understand that r, g, b can contain separate alpha values for 
> each component (which I easily could support in my driver since I first 
> need to build an accelerator-suitable texture anyway). What is supposed 
> to happen with the 4th, the a component?
> 
> >  XAA's render support was written in the early days of render,
> > back when render didn't support as much stuff as it does now.
> > It probably makes sense for XAA to only pass them through when
> > componentAlpha is not set, then it would be up to the driver
> > to decide whether or not it can just extract the alpha portion,
> > and punt if it doesn't.
> > 
> >  We should probably be adding
> > 
> >   if(pMask->componentAlpha)
> >         return FALSE;
> > 
> >  right after the if(pMask) test to reject the 4-component alpha
> > condition.
> 
> What if some hardware supported this? Wouldn't it be better to set a 
> flag in the Flags field submitted to the driver's SetUpCPU...() 
> function? Or/and perhaps let the driver specify a flag in the 
> CPUToScreenAlphaTextureFlags, like XAA_RENDER_COMPONENT?

   If you want to test that, you can add it, though I'd recommend
waiting until after 4.4.  I've already checked in code that has
XAA bail out when it sees componentAlpha.

   In order to avoid breaking binary compatibility, you'd need
to add a flag to the CPUToScreenAlphaTextureFlags that allows
the driver to say that it supports per-component alpha.  Otherwise
all the current drivers would need to be rewritten to recognize
the new flag.


                        Mark.


_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Reply via email to