Re: Question with regards to componentAlpha

In your message of 14 September 2002 you write:

> 
> Around 15 o'clock on Sep 14, Thomas Roell wrote:
> 
> > Ah, that is true. Forgot about color index rendering. BTW, why did you
> > decide to have the alpha channel of color index mode (PseudoColor) to
> > be 0, while for example r5g6b5 has a alpha value of 1.0 ?
> 
> Indexed formats have an alpha value for each pixel; you'll see in the 
> current render/miindex.c that the sample implementation sets alpha to 1 
> for each pixel.

Then the spec is wrong. It says:

	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. 


Also two other issues we ran into. You do set up this translation
table for index to color. What happens if the index is outside the
defined color-cube ? I mean, the rest of it is pretty much colormap
specific.

The other thing is more tricky. OpenGL allows you to have an
alpha-channel. Is this notion of the alpha-channel shared with XRENDER
? I mean we tried to expose this via a visual with a depth of 32 and
32 planes (a8r8g8b8). However half of the desktop would be drawn
wrong. On the other hand if only a depth of 24 is exposed (and 24
planes), then in reality the alpha channel is either never written
(using HW planemask, at a significant price), or written with random
data. The question is how should this be handled from your experiance.

> > Well we got here with "x11perf -aa10text" on a specifc platform 
> > in SW mode around 60000 glyphs per second, while we got 2480000 glyphs
> > per second in HW. The SW solution was barely usable for scrolling in a
> > terminal. The fbpict.c code was rated at 41000 glyphs per seceond.
> 
> I think your definition of "barely usable" and other peoples aren't quite 
> the same.  I've been using X for a while, and 40000 glyphs/sec provides 
> adequate, if not blinding performance for daily work.  Certainly it would 
> be nicer to have hardware acceleration for all operations, but when the 
> necessary operation doesn't match the hardware, then it will go a lot 
> slower.  Fortunately, CPUs are fast enough to provide a level of 
> performance acceptable to most people.

The problem seems not to be the CPU, but the readback path via AGP. I
have been writing X-Server and drivers since 1990, and yes initially
you had a lot of SW involved. However since at least 1994 pretty much
100% of the subset of X11 that was used widely is pretty much done in
HW.

> Please feel free to propose an alternative which provides for per-component
> rendering for text and graphics operations.

I was suprised that you didn't simply choose the OpenGL/DX7 blending
model, and implement more complex algorithms ontop of that. 

> > For SW I agree. For HW you still owe me at least one example. My point
> > of criticism here is really that we need to live with what we got in
> > terms of HW. 
> 
> I don't have permission to publish any examples of per-component capable 
> hardware.

Let's back up here a little bit. What I am trying to find out is
whether I misread the spec and stuff is really implementable fully
in HW on a platform I do know, or whether there is misreading on your
side about possible HW capabilities. That's why I would love to have
an example of HW that I know about.

We do have NDA's with the following companies:

	3Dlabs
	ATI
	Intel
	Matrox
	Trident
	S3 Graphics
	SiS

I might not have read all the chipsepcs for all their chips, but we do
have them here, so I could look them up pretty easily. Giving me a
pointer would be quite helpful.

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