Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!ukc!acorn!john
From: john@acorn.co.uk (John Bowler)
Newsgroups: comp.windows.x
Subject: Re:  Xsun on cg4 (Sun 3/60)
Message-ID: <1798@acorn.co.uk>
Date: 7 Mar 90 18:40:18 GMT
References: <9003060725.AA00997@Larry.McRCIM.McGill.EDU>
Reply-To: john@acorn.UUCP (John Bowler)
Organization: Acorn Computers Ltd, Cambridge, UK
Lines: 23

In article <9003060725.AA00997@Larry.McRCIM.McGill.EDU> mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) writes:
[talking about R4 on a SUN 3/60]
>
>(Actually, the 1-bit screen *should* be a PseudoColor screen; that's
>what the hardware is.  But StaticGray was easier, no doubt.)

Last time I tried making a server do this a very large number of the
clients (I admit, R2 clients) became unhappy.  The problem is an
exaggerated example of the ``running out of colours'' problems people
have with shallow PseudoColor displays; the first 3 applications get
the colours they want, then all the following applications get Alloc
errors from AllocNamedColor, because there are no more slots in the
default colormap :-).

On a display with a default depth 1 PseudoColor visual there are no
free colormap cells in the default map - because the server has already
allocated White and Black for the black and white pixels.  It has all
the attributes of a StaticGray display but none of the advantages; in
particular Alloc[Named]Color never fails on a colormap from a static
visual through not being able to arrange for a suitable (:-)) colour
in the colormap.

John Bowler (jbowler@acorn.co.uk)