Re: Question with regards to componentAlpha

In your message of 16 September 2002 you write:

> 
> 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.

Guess there is then no usable solution for now ;-(

> > 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."

This is relative to "direct" formats only.

> > 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."

Yep, that sound better.
 
> > 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.

That and maybe some guidance for allpications for to use the new
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.

Which they don't as either they use QueryColor, or simply assemble the
pixel value without taking the alpha component into consideration.

> > 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.

We opted not to. If youn also support OpenGL, have this additional
number of visuals bumps up the number from 50 to 100 in our
environment.

> > 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.

Well, it would have worked with other CPUs, where you can explicitely
specify a set of cachelines to be flushed directly, rather than to
flush the whole cache.

> > 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.

What is fundamentally wrong with switching from	using

	(src.a * mask.b, src.a * mask.g, src.a * mask.r, src.a * mask.a)

to

	(src.b * mask.b, src.g * mask.g, src.r * mask.r, src.a * mask.a)

If the differing per channel application of src.a would be needed one
could implement this using a simple multipass scheme.

An application can much easier split up things into multiple
passes. Spliting up things at the driver backend is tricky, as one
cannot really combine multiple incoming passes into a single pass,
even if it would be possible.

- Thomas 
-- 
	     Thomas Roell   /\	       Das Reh sprint hoch,
	     Xi Graphics   /  \/\ _     das Reh springt weit,
	 [email protected]	  /   /	 \ \	 was soll es tun,
			 / Oelch! \ \     es hat ja Zeit.