Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!news.cs.indiana.edu!sdd.hp.com!usc!jarthur!nntp-server.caltech.edu!madler
From: madler@nntp-server.caltech.edu (Mark Adler)
Newsgroups: comp.sys.next
Subject: Re: bits per pixel (was: NeXT General Educational Disqucount?)
Message-ID: <1991May12.190049.21197@nntp-server.caltech.edu>
Date: 12 May 91 19:00:49 GMT
References: <1991May12.044514.329@cbnewse.att.com> <1991May12.052853.27513@neon.Stanford.EDU> <2776@public.BTR.COM>
Distribution: usa
Organization: California Institute of Technology, Pasadena
Lines: 30


David Burrowes comments on the transparency bits:
>> Obviously, even if this is so for the Megapixel monochrome/grey/whatever
>> screen, it ain't true for the color machines!

Well, no.  The fellow who said "or even 2+2, 12+4, or 24+8 bit." was
excruciatingly correct.  The value to the left of the plus is the
number of bits per pixel in the actual display buffer, that generates
the intensity for the electron beam(s).  The value to the right of the
plus is the number of bits assigned to each pixel's "transparency".
The sum (4, 16, or 32) is the number of bits per pixel that DPS maintains
for the windows.  DPS uses those bits when overlaying windows in the
display buffer from its own window buffers.

We saw a very nice demo of that at the last SCaN meeting, where a
Ferrari with somewhat transparent windows and a butterfly with somewhat
transparent, colored wings were moved over a beach/mountain scene
on a NeXTdimension.

If you look carefully at the specs for the color slab, you will see it
says "1.5 MB VRAM", which comes out to 12 bits/pixel for a megapixel
display.  I don't know why the NeXTdimension has (claims) 4MB VRAM.
It only needs 3MB for the display buffer.  Perhaps the other ram is
for buffering incoming or outgoing NTSC video.

Now that I think about it, 640*480*3 is 921600 < 1M.  I'll bet that's
it.

Mark Adler
madler@pooh.caltech.edu