Re: Question with regards to componentAlpha

In your message of 14 September 2002 you write:

> 
> Around 14 o'clock on Sep 14, Thomas Roell wrote:
> 
> > Would you mind send this one over our way early, as we implemented
> > the whole extension independantly, and hence might have more
> > clarifications.
> 
> As with all of the XFree86 distribution, the Render spec is available via 
> anonymous CVS; I'll post a note when I'm done making edits.

I cannot use anonymous CVS throu our firewall ;-(

> > Why doesn't render support planemasks (or channel-masks) anyway ?
> > OpenGL/DX7 do, and hence HW does.
> 
> Because Render supports all X visuals, including StaticColor and 
> PseudoColor which can't always be split into separate channels.

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 ?

> > Sorry to say, but my experiance with render is exactly the opposite way
> > around. The wording in the spec is very often extremely unclear, and only
> > by looking at the fbcomposite.c/fbpict.c code it becomes clear what could
> > have been meant.
> 
> I'm not surprised; the Render spec needs some more concentrated effort at 
> clarity, but that work isn't at the top of my agenda.  I'd appreciate 
> concrete proposals for wording changes.
> 
> > Here now a quick analysis of the problem that we have found with regards to
> > implementability.  With a normal 3D pipeline blender you cannot do this
> 
> You need lower level access to the hardware; the usual 3D abstractions 
> provided are certainly not sufficient for this operation.  As this is used 
> primarily for text, performance of the software version is acceptable.

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.

> > So esstentially you either have to use 4 passes with planemasking, you
> > you cannot do this in HW.If you have to use 4 passes anyway, the
> > question becomes then, why not to let the application explicitely use
> > 4 passes instead.
> 
> Because the logical operation is unified and consistent, and some hardware 
> (and software) can perform this in a single pass.  Feel free to implement 
> it however you like.

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 would be surprised if ANY HW vendor changes their
design to match the requirements of render. That's why I feel the spec
is odd in some places requireing semantics that precluse an reasonable
HW acceleration.

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