Xref: utzoo comp.windows.x:24456 comp.windows.x.motif:91
Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!zaphod.mps.ohio-state.edu!mips!smsc.sony.com!dce
From: dce@smsc.sony.com (David Elliott)
Newsgroups: comp.windows.x,comp.windows.x.motif
Subject: Re: Colormaps
Message-ID: <1990Jul16.143947.16670@smsc.sony.com>
Date: 16 Jul 90 14:39:47 GMT
References: <1990Jul13.183517.23734@media.uucp> <59@maxx.UUCP> <1990Jul16.134303.2465@smsc.sony.com>
Sender: news@smsc.sony.com (Usenet News System)
Reply-To: dce@smsc.sony.com (David Elliott)
Organization: Sony Microsystems, San Jose, CA
Lines: 25


In article <1990Jul16.134303.2465@smsc.sony.com>, dce@smsc.sony.com
(David Elliott) writes:
|> The algorithm given by der Mouse is probably the best way to go, with
|> the additional user-option to use the default colormap if it's large
|> enough.

Oops.  I really meant something intelligent here.  By "if it's large
enough", I meant "if it has enough free cells".

As a side note, it seems to me that the color cell allocation routines
in X could remember the last cell allocated and start there unless otherwise
directed.  This would mean that color backgrounds created by connections
that no longer exist would stay correct longer, and that programs that
allocate private colormaps would generally start using unused cells
first.

Or, maybe it would be good enough to add a "allocate from the end of
the colormap and go backwards" option to the color cell allocation
routines.

...David Elliott
...dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce
...(408)944-4073
..."You know my motto: Forgive and uh... the other thing."