Re: Mac 32 bit color depth?

[Randall Frank <rjfrank1(at)home.com>]

Here he goes again...

<soapbox>
 	Let me try to add some context to things here.  It 
seems people are a bit confused as to what is meant by 32 
and 24 bit color, particularly for 2D (Direct) graphics.
With the exception of a few (older) Macintosh gfx cards,
32 bit color generally means that pixels are addressed as
32 bit quantities instead of 24 bit quantities.  32 bit mode
is generally faster (due to pixel alignment issues) and in
many cases, the extra 8 bits are actually inaccessible (and
on some cards they do not exist).  There are some Mac cards 
that map the color space to CMYK (as noted earlier) for more 
accurate color registration.  Don't confuse issues of destination
alpha with those of source alpha.  Supporting blended draws
(as Object Graphics do) is more a function of source alpha
and in most cases matters not if the destination is 24 or 32
bits.  Just because a card has a "32 bit" visual, does not
mean it has a "transparency" HW channel.  The biggest bang 
for the buck comes in supporting source alpha, blended 
drawing modes which have nothing to do with the question
of 32 vs 24 bit visual support.
</soapbox>

<blithering>
	The real question is what abstraction of these 
issues would be useful in IDL?  Source alpha is in Object
Graphics already.  It does not require HW alpha plane support,
and thus tends to be fairly universally supported by both 3D 
and 2D APIs.  Destination alpha is supported in common 3D APIs 
but not as many 2D APIs.  I have heard one request for destination
alpha (wrt png) in the previous discussions, but would ask 
seriously  how one intends to use the destination alpha 
channel.  Given the complexities of pixel formats exposed 
in DG already, I might question the value of exposing 
another, especially given cross-platform issues.
</blithering>

<IMHO>
	In short, source alpha might be useful in DG
(but can easily be done yourself in the existing API for
many applications).  Destination alpha should be considered
carefully, particularly outside of 3D APIs.
</IMHO>

> > In article <thierry-2203011142210001@dualpants.dev.rsinc.com>,
> > thierry@NOSPAM.rsinc.com (Thierry Faucounau) wrote:

<insidejoke>
Thierry, "dualpants.dev."?  My preference, of course, "nicepants.",
the original :).
</insidejoke>

> >
> >     Thierry, that sounds very reasonable --- but it would be great to be
> > able to access the transparency channel: I would love to be able to
> > create movies (e.g. with XINTERANIMATE) in IDL that include transparency
> > effects.

<ruminate>
Interesting, yes.  But potentially a loaded issue, given the way 
XINTERANIMATE works (e.g. its use of pixmaps).  I might inquire what
kind of transparency effects?  Cross fades and the like, accumulation
like effects or stenciling?  You may be actually asking for quite
a bit more from XINTERANIMATE (e.g. multiple source channels).
</ruminate>

> 
>   And wouldn't it make the creation of .png files a little easier?
>   Don't they support a native RGBA?

<tersecrypticreply>
IMHO, ATC, no.
</tersecryticreply>

Man am I in a strange mood today... :)

rjf.