death@public.BTR.COM (David Burrowes death@btr.com) (05/13/91)
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! \david john burrowes death@btr.com
madler@nntp-server.caltech.edu (Mark Adler) (05/13/91)
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
ly@neon.Stanford.EDU (Eric Ly) (05/13/91)
In article <2776@public.BTR.COM> death@public.BTR.COM (David Burrowes death@btr.com) 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! This is my guess as to the way it works. The frame buffers for the Monochrome, NSC, and ND screens are indeed 2 bits, 12 bits and 24 bits in depth, respectively. What you talk about alpha, you talk about them in the context of PostScript pixelmaps, which are independent of screen display capabilities. Depending on whether you choose to or not, DPS will allocate an extra 2 bits, 4 bits or 8 bits to be associated with each pixel in the pixelmap. You probably don't get a choice as to the number of bits allocated for alpha, as it depends on which machine you're using. These extra bits define the transparency of the data for each pixel. When two images are merged together, DPS uses the transparency values associated with each overlapping pixel to compute the resulting color for that overlap. The alpha is used to _derive_ the resulting color, but the resulting color is "opaque" in the frame buffer. This alpha information can also be saved with the data portion of the pixelmap. So, it's indeed possible to display a 32-bit (8+8+8+8) pixelmap on a monochrome screen; it's just that the 8 bits of alpha cannot be taken into full account during compositing beyond, say, the two high-order bits of the alpha. It's rather like trying to render an 8-bit data image onto a 1-bit display, except in this case, it relates to alpha. This may not be completely accurate, but it's the way I understand it. Eric Ly Stanford University
king (Peter King) (05/14/91)
In article <1991May12.205753.23335@neon.Stanford.EDU> ly@neon.Stanford.EDU (Eric Ly) writes: > This is my guess as to the way it works. The frame buffers for the > Monochrome, NSC, and ND screens are indeed 2 bits, 12 bits and 24 bits > in depth, respectively. > <<major ellipsis>> Actually, the VRAM for the MegaPixel Display, NeXTstation Color, and NeXTdimension are 2 bits, 16 bits, and 32 bits per pixel in depth, respectively. For display, the NeXTstation Color uses 4 bits each of RGB, and the NeXTdimension uses 8 bits each of RGB. The extra 4|8 bits aren't used by the display hardware; they pad each pixel to be halfword|word aligned for optimal memory bus performance. The depth of a particular window (what Eric calls a "PostScript pixelmap") is indeed independant from the depth of the display. When a particular window is displayed on the screen, it is automatically dithered to the depth of the VRAM. Each window depth can have an "alpha channel" associated with it. This contains a transparency value for each pixel which is used during compositing (overlaying of bitmap images). There are currently four window depths to choose from: NX_TwoBitGrayDepth 2 bits gray + 2 bits alpha NX_EightBitGrayDepth 8 bits gray + 8 bits alpha NX_TwelveBitRGBDepth 4 bits each RGB + 4 bits alpha NX_TwentyFourBitRGBDepth 8 bits each RGB + 8 bits alpha In the case of the grayscale window depths, memory to store the alpha channel is allocated lazily. That is, the Window Server will only use 2|8 bits per pixel unless you start drawing with transparent ink. This will cause the backing store for your window will double in size to accomodate the alpha channel. Note that the alpha values for the color window depths exactly match the amount of padding used for halfword|word alignment. The Window Server will always allocate 16|32 bits per pixel for the color depths. With color windows, you always get your alpha channel whether you use it or not. Since the display hardware doesn't touch the alpha channel, it is safely preserved in VRAM as well as backing store. This is great for Retained windows! Peter ----------Disclaimers? No such thing. Everything's the truth---------- Peter F. King Developer Trainer NeXT Computer, Inc. USPS: 900 Chesapeake Dr. Redwood City, CA 94063 Internet: Peter_King@NeXT.COM
pgraff@next.com (Peter Graffagnino) (05/14/91)
In article <721@rosie.NeXT.COM> king (Peter King) writes: ...... >backing store for your window will double in size to accomodate the alpha >channel. > >Note that the alpha values for the color window depths exactly match the amount >of padding used for halfword|word alignment. The Window Server will always >allocate 16|32 bits per pixel for the color depths. With color windows, you >always get your alpha channel whether you use it or not. Since the display >hardware doesn't touch the alpha channel, it is safely preserved in VRAM as >well as backing store. This is great for Retained windows! > >Peter > > >----------Disclaimers? No such thing. Everything's the truth---------- >Peter F. King Developer Trainer NeXT Computer, Inc. >USPS: 900 Chesapeake Dr. Redwood City, CA 94063 >Internet: Peter_King@NeXT.COM Peter is nearly correct. On NeXTstation Color we actually only use 12 bits per pixel of VRAM for the display. From the CPU, the framebuffer looks like an array of 16 bit pixels with the low nibble of each pixel tied high. On NeXTdimension, we have the full 32bits per pixel of VRAM. In this case the low-order byte is used for storing pixel `tags' for the RAMDAC. This allows us to support 12bit double buffered pixels as well as 24 bit single-buffered pixels. (our current software does not take advantage of this feature, however). In no current NeXT framebuffer implementations is alpha ever stored in VRAM arrays. As far as Retained windows go, the WindowServer actually notices when a window acquires alpha by monitoring the drawing commands issued to it. If a Retained window has never had alpha drawn into it (and the backing store's depth matches that of the VRAM), drawing will occur directly into VRAM. Otherwise, Retained window drawing will actually occur into the backing store first (in order to capture the alpha data), followed by an implicit flush to the screen. This is one of the reasons why it is important not to use alpha in on-screen windows (the extra flush is expensive). Typically, windows with alpha are used for off-screen drawing caches (such as those managed by the appkit's NXImage object) which are then Sover'ed onto an onscreen window for presentation to the user. Peter Graffagnino Graphics Software NeXT Computer, Inc.
scott@nic.gac.edu (Scott Hess) (05/14/91)
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>
aozer@next.com (Ali Ozer) (05/15/91)
In article <SCOTT.91May13212139@nic.gac.edu> Scott Hess writes: > ... Also, the window won't get deeper (in bits) than the hardware supports. It can; however, by default, apps limit the window depth limits to the depth of the deepest frame buffer available to the system. You can increase (or decrease) this depth limit through the setDepthLimit: method in Window or setwindowdepthlimit operator in the window server. NXImage also provides a method to allow you to open image files in their full depth (rather than the depth limit of the app). > ... 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). Eight; depth of the alpha channel is the same as the depth of the other channels (grayscale channel or each channel of RGB). This fits nicely into the PostScript model of image data. Ali, Ali_Ozer@NeXT.com