Re: Question with regards to componentAlpha

Around 10 o'clock on Sep 16, Thomas Roell wrote:

> The bug as you found is not in our render implementation, it's more
> the fact the normal X11 drawing by default will put alpha to be 0.0.

Core rendering will set alpha to whatever value is in the pixels provided
by the client.  To usefully use depth 32 windows with core requests, you'll
have to fix the application to set the upper bits.  Or, have them stop
using core rendering and switch entirely to Render graphics which doesn't
have this limitation.

> Yes, INDEXVALUE has a alpha value, but the section I was citing
> indicates that the alpha-value would be zero.

The intent was to specify that the values passed in the DIRECTFORMAT
structure would all be zero.  The misleading wording is the explicit 
mention of 'alpha channels' as they don't have red, green or blue channels 
either but rather use a lookup table to fetch all four.

The alternative would have been to leave the DIRECTFORMAT values 
unspecified, but that seemed messier to me and could lead to simplistic 
applications attempting to use the wrong picture format.

And, your question about the particular sequence of operations involving 
component alpha is already described by:

 "When the mask contains separate alpha values for each channel, the
  alpha value resulting from the combination of that value with the source
  alpha channel is used in the final image composition."

> Ok. Could you update the upper section please to state that is a
> picture format has no alpha channel, the aplha channel is assumed to
> be 1.0.

Already done in section 7:

 "A Direct PictFormat with zero bits of alpha component is declared to have
  alpha == 1 everywhere."

> And then be explicite for the index case that the red, green
> and blue components are taken from the colormap.

Yes, I can add wording like that.  How about:

 "Indexed PictFormats never have alpha channels and the direct component is all
  zeros.  Indexed PictFormats always have a colormap in which the specified
  colors are allocated read-only and are therefore screen dependent.  Drawing
  to in Indexed Picture uses only pixel values listed by QueryPictIndexValues.
  Reading from an Indexed Picture uses red, green and blue values from the
  colormap and alpha values from those listed by QueryPictIndexValues.  Pixel
  values not present in QueryPictIndexValues are given alpha values of 1."

> It has to, as both have a notion of alpha channels that might be
> associated with a window (or pixmap).

Only if you want to draw to a window with both OpenGL and Render at the 
same time, which few applications are brave enough to attempt.  Probably 
what's needed is some sort of inter-extension cooperation on the meaning 
of per-pixel alpha values.

> The bug as you found is not in our render implementation, it's more
> the fact the normal X11 drawing by default will put alpha to be 0.0.

Normal X11 drawing uses pixel values provided by the client.  If the 
client wants to set the upper 8 bits to 0xff, those pixels will be opaque.

> One idea here was to always set alpha to be 1.0 (i.e. adding it to the
> fgPixel/bgPixel of a GC). But that would mean that you cannot really
> access the alpha channel under X11, and hence you might as well not
> expose the channel (which we opted to do).

With a depth 32 window, this violates the X11 spec.  Depth 32 drawables 
must have all 32 bits addressable by the application.

Using a depth 32 drawable with the core protocol will require changes to 
applications to manage the upper 8 bits.  I suggest that the depth-32 
visual not be the default so that only knowledgable applications will 
attempt to use it.

> Correct. However this seems to be inelegant, as would now have no
> window picture formats that have an alpha channel.

You may advertise both depth 24 and depth 32 windows.

> That does not work. The AGP spec (well, more the databooks of the
> northbridges that is) allows that the fetches that travel over the AGP
> bus are not snooping the CPUs cacheline(s). Hence you would have to
> manually flush dirty cache lines. As far as I understand this, the
> IA32 design does not allow you to flush individual cache lines.

It can work, but as you point out, it involves a lot of manual cache line 
flushing which turns out to be another significant performance problem as
the entire cache must be flushed when switching from hardware to software 
rendering.  Hence the approach was shelved without even trying it.

> I am not surprised that they are not, and I would not be surprised if
> they would never be.

The land of 3D consumer graphics moves ever closer to that used in the 
professional 3D rendering world; as this kind of functionality has been 
present in Renderman for nearly twenty years, I wouldn't be surprised to 
see it move into applications at some point.  But, then again, I wouldn't 
be surprised if it didn't.  

I don't really care if all hardware can accelerate this operation, it's a
very powerful capability which can dramatically improve the appearance of
text on an LCD screen.  As I've said, I'm very interested to hear of
alternative specifications which satisfy the fundemental requirements.

Keith Packard        XFree86 Core Team        HP Cambridge Research Lab