Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!cs.umn.edu!uc!noc.MR.NET!gacvx2.gac.edu!gacvx2.gac.edu!scott
From: scott@nic.gac.edu (Scott Hess)
Newsgroups: comp.sys.next
Subject: Re: bits per pixel (was: NeXT General Educational Disqucount?)
Message-ID: <SCOTT.91May13212139@nic.gac.edu>
Date: 14 May 91 02:21:39 GMT
References: <CNH5730.91May10133848@maraba.tamu.edu><1991May11.075053.10746@ccu.umanitoba.c
 a><1991May12.044514.329@cbnewse.att.com><1991May12.052853.27513@neon.Stanford.EDU> <2776@public.BTR.COM>
Distribution: usa
Organization: Gustavus Adolphus College
Lines: 53
Nntp-Posting-Host: nic.gac.edu
In-reply-to: death@public.BTR.COM's message of 12 May 91 17:53:12 GMTLines: 53

In article <2776@public.BTR.COM> death@public.BTR.COM (David Burrowes  death@btr.com) writes:
   In article <1991May12.052853.27513@neon.Stanford.EDU> ly@neon.Stanford.EDU (Eric Ly) writes:
   >In article <1991May12.044514.329@cbnewse.att.com> cafe@cbnewse.att.com (richard.dib) writes:
   >>> I think 4, 16, or 32 bit is more accurate.
   >>> or even 2+2, 12+4, or 24+8 bit.
   >>Why 4 bits???  There are only four diferent "shades" on the B&W monitor: 
   >The 4 bits, or 2+2 bits, refer to two bits of data and two bits of

   I condeed in advance that I may be way off in la-la land here, but it
   runs in my mind, from something I distantly remember reading back in the
   0.8, 0.9 or 1.0 docs that the 2 transparancy bits were allocated 'on the fly'.
   That is, by default, the screen is 2 bits deep, but when one needs to go
   do transparancy work, enough extra bits are allocated for this purpose
   by DPS or whoever.
   Obviously, even if this is so for the Megapixel monochrome/grey/whatever
   screen, it ain't true for the color machines!

Differentiate between the _window_ and the frame buffer.  The window
exists as a piece of memory off by itself for Buffered windows,
as a combination of memory and frame buffer for Retained, and simply
as stuff in the frame buffer for Non-Retained.  The _frame_buffer's_
depth is defined by the hardware the stuff is running on.  Meanwhile,
the _window's_ depth is defined by a couple things.  For one, the
programmer can limit the depth of a window.  Also, the window
won't get deeper (in bits) than the hardware supports.

But, you can define a 2+2-bit window on the color machines, and
have it only use that many bits.  Also, the depth-promotion works
for the number of bits, too (besides transparency).  So, unless
you force it, a window comes up with 2-bits, no transparency.
If you draw a color in it, and there is not a limit on depth,
it will be promoted to be deeper, as needed to represent what
you're drawing.  Same with alpha - unless forced, you won't
have alpha unless you try to use it, at which point it's
created for you.  This is why alot of stuff on the color
machines isn't all that slow - most apps don't use more than
the basic 2 bits, so no more is required in the window's
backing store (most windows on NeXT are Buffered, and thus
have a seperate backing store).

Also, there's a depth that the software _seems_ to support
(OK, the include files indicate it's there), but there's no
corrosponding hardware for - 8-bit deep monochrome.  I'm not
sure what the alpha on this depth is, but it's probably
4 or 8 (2 would seem a little limiting).  Maybe NeXT will
fill the gap in their product line?  I'd by two or three.
Esp. if they packed an on-board i860.

Later,
--
scott hess                      scott@gac.edu
Independent NeXT Developer	GAC Undergrad	<almost out!>
<I still speak for nobody>