Re: Palette hogging

[David Kastrup <dak neuroinformatik ruhr-uni-bochum de>]

   From: raster@redhat.com
   Date: Thu, 26 Mar 1998 09:50:17 -0500 (EST)

   ->  The problem is that it looked very much like the desktop would gobble
   ->  up a substantial number of colours, while many people have only one
   ->  small palette (typically 256 colours) available on their system.
[...]

   have you actually RUN any parts of gnome? :)

The last time I tried (0.09 or something) there were just a few
obscure games, and a "task bar" which would be just blank.  Available
documentation in the binary distrib I tried would not be of much help
in figuring out more.  So I decided to wait until the developers would
announce a version they would consider as fit for general use
including documentation before I experimented again.

   all the "colro hogging"
   bits liek icons etc. use imlib for their creation. The advantage...
   Imlib is ruthless about maintaining lean color management on
   pseudo-color displays (http://www.labs.redhat.com/imlib/tut/) you can
   force imlbi to use a defined palette fo colros - the default being
   about 40 colors. it will use only as many as it is told.

It always comes as a pleasant surprise to me if I hit upon the fact
that other people can think as well.

   ->  Another thing that might be nice to have (but I don't know which
   ->  component would be resposible for that) is smart allocation of
   ->  additional colour maps.  By this I mean some mechanism that tries to
   ->  allocate similar colours to the same indices in multiple colour maps.
   ->  That way, switching the colour maps when going between windows would
   ->  not be as eye-jarring an experience as it is often now.

   the Color Context stuff tries to do this. if applications use Imlib
   alreday allocated palete (use gdk_imlib_best_color_match) then no extra
   colors will eb allocated, but imlib will return a best match (and an
   error on how far off that clostest match is to the desired color),
   allowing the user full control over ALL color management bu simply
   defining the set of colors used to suit their needs best.

That's not what I mean.  I mean that when an application demands a
full colormap of its own, then that should be arranged somewhat like
the default color map.  This means, for example, that a pretty red
color would get the same index as the red in the default color map,
while still being given the exact shade of demanded red in its own
color map.  When now the default map and the application color map get
switched, the display of a pixel changes from one red shade to another
which is visually less disturbing than a change from red to green.

Of course, this will work best if the application requests all colours
at once, yet will obey an indexing scheme proposed by the colour
management library in answer.

It is somewhat more difficult to assign colours if they are asked one
by one, but one could still do some closest match strategy.

Unfortunately, such a scheme would be rather incompatible with
techniques that demand allocating consecutive colour blocks from a
palette, so this "close match to rest of desktop in my own palette"
functionality would have to restricted to applications that were sure
not to meddle with colourmaps in that way (probably no problem if
Imlib and Xlib colour management calls were not mixed).

Your observation that 8-bit displays get hazed out anyhow is basically
correct.  Unfortunately, the principal development focus of systems
like Linux is lacking the impact of technological drive of systems
like Windows95/98/whatever that make sure that software evolution
(survival of the fattest) is closely coupled via usability
expectations to hardware upgrades.  For example, I have not been able
to convince my girlfriend that her text processing and general
computing needs require more than her current 486DX2/66 ISA bus system
with 24MB of RAM is capable of delivering with
X/Emacs/LaTeX/GhostScript etc.

A system allowing serious work under current Win95/Word is of a
vintage rendering obligatory usage of pseudocolor improbable.  Sadly,
a usable Linux system might use a lot more outdated hardware.  One
should not entirely forget this.

David Kastrup                                     Phone: +49-234-700-5570
Email: dak@neuroinformatik.ruhr-uni-bochum.de       Fax: +49-234-709-4209
Institut für Neuroinformatik, Universitätsstr. 150, 44780 Bochum, Germany