Re: Question with regards to componentAlpha

Around 13 o'clock on Sep 14, Thomas Roell wrote:

> I you suggest using explicite formulas like I used in my example would
> clarify things quite a bit.

I'll do that; I'm currently cleaning up the Render spec as I add 
projective image transformations.

> I'm not to much arguing the usefullness of the operation, although it
> seems to be overcomplicated and does not mach very well current
> hardware.

The complexity is as required by the desired operation; we want 
to treat each sub-pixel separately with it's own alpha value all the
way through the basic computation.  If image compositing did planemasks,
we'd do this in four passes, one for each component of the signal (well, 
on TrueColor hardware at least) with separate mask pictures to modulate 
the source image as appropriate.

> It is just very frustrating for somebody to actually implement the
> extension using the spec as a reference and then running into convoluted
> cases like this where IMHO the spec contradicts itself.

That's why I always like to see additional implementations for each spec.  
The X11/NeWS server performed some of the same tasks for the core 
protocol, discovering inconsistencies in the specification and errors in 
the sample implementation.

The Render spec has seen very little detailed analysis like this; there 
are many areas which could use clarification.  The important thing is that 
the intent is to make the spec the standard, and not the XFree86 
implementation, but inconsistencies between the XFree86 implementation and 
the spec may show either bugs in the code, or a mistatement in the spec,
or both.  It's an incremental process, and one which so far has been 
working better than most of the specs developed by the X consortium.

Keith Packard        XFree86 Core Team        HP Cambridge Research Lab