🚀 go-pugleaf

In article <1992Oct30.235141.4139@kakwa.ucs.ualberta.ca> gary@nshade.uah.ualberta.ca (Gary Ritchie)  
writes:

>    dwrite -g NXWindowDepthLimit TwoBitGray
>
>Have others tried this technique before?  Is my machine really going  
>faster, or am I just light-headed from hunger late on a Friday afternoon?
>

This will not necessarily speed up an app.
It depends on the app.  FrameMaker 3.0 performs much better when the
window depth is promoted to match the display.  It crawls when the
window is in 2-bit gray depth on a Color station.


--
Izumi Ohzawa             [          ]
USMail: University of California, 360 Minor Hall, Berkeley, CA 94720
Telephone: (510) 642-6440     Fax:  (510) 642-6341
Internet: izumi@pinoko.berkeley.edu (NeXT Mail OK)

Gary Ritchie writes
-> 
-> The easiest way to play with these things is via the DefaultMgr  
-> application available on the archives.  The EightBitGray option looks  
-> quite nice, but doesn't save much memory over 12 bit color.
-> 

This is a bad move. The EightBitGray option makes imaging even slower than  
twelve bit.


--

Kevin Solie

kevins@ms.uky.edu
kevins@slow.inslab.uky.edu (NeXT Mail)

In article <1992Oct30.235141.4139@kakwa.ucs.ualberta.ca> Gary Ritchie writes:
>What I have done is to turn off color by default in ALL applications with:
>      dwrite -g NXWindowDepthLimit TwoBitGray
>...you can reenable color selectively, ie:
>      dwrite GoldDigger NXWindowDepthLimit TwelveBitRGB

What a fine choice of an app to run in color. 8-)

>Have others tried this technique before?  Is my machine really going  
>faster, or am I just light-headed from hunger late on a Friday afternoon?

The window server uses lazy promotion to assure that windows remain skinny
until they need to draw some color that cannot be represented in the current
depth. All windows start life out as 2-bit windows, the moment you draw
one of the non-standard 4 grays, they get deeper. This promotion
continues upto the time the windows reach their depth limit.

On a 2-bit machine, all windows are depth-limited to 2-bits (by default). Thus
windows will never get deeper than 2 bits. On a NSC, they are depth limited
to 12 bits. Thus, by doing the TwoBitGray dwrite on a NSC, you are simply
making all windows remain at 2 bits.

This operation will save memory; backing stores of would-be color windows
now occupy 8 times less memory. It can also speed up drawing, depending on the
type of drawing operations. However, it does slow down the flush from the 
backing  store to the screen in some cases; for instance, flushing an 8-bit 
window to a 12-bit screen isn't too zippy. Flushing a 2-bit window to a 12-bit
screen is pretty quick, so it is conceivable that your machine might seem a 
bit faster with a 2-bit window depth limit. The reduced swapping probably
helps as well, when switching between apps.

One final note... Flushing 2-bit windows with alpha to a 12-bit screen is
rather slow, and I believe this is what causes Frame to run real slow
on a NSC when the window depths are limited. If you don't limit the
depth, Frame's windows become 12-bits (with alpha), and in that case the
flush is much faster.

Ali, Ali_Ozer@NeXT.com

In article <5795@rosie.NeXT.COM> aozer@next.com (Ali Ozer) writes:

   One final note... Flushing 2-bit windows with alpha to a 12-bit screen is
   rather slow, and I believe this is what causes Frame to run real slow
   on a NSC when the window depths are limited. If you don't limit the
   depth, Frame's windows become 12-bits (with alpha), and in that case the
   flush is much faster.

   Ali, Ali_Ozer@NeXT.com


I don't limit the depth (at least I did nothing to limit it), but
FrameMaker runs real slow on my NSC after it is launched.  To speed it
up, I change some characters to Red, then back to black, thus,
according to Ali's explaination, promotes the windows to 12 bits.
Is there an easier way?









--
Paul F. Kunz	pfkeb@slac.stanford.edu (NeXT mail ok)
Stanford Linear Accelerator Center, Stanford University
Voice: (415) 926-2884   (NeXT) Fax: (415) 926-3587