Re: Palette hogging

[raster redhat com]

On 26 Mar, David Kastrup shouted:
->     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.

ahh well a lot has happened since then... :)

->  
->     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.

yes.. I understood what you meant.. that is what I understood. The
colorcontext stuff tries to allocate the whole palette at onc.e. but
doenst odo this matching.. th eproblem wiht this matching is that an
app that needs a private colormap often also depends on the order of
the colros int hat colromap... thus negating tha baility to do what you
sauggest.. the problem can't be solevd by gnome - it is apps such as xv
and netscape that will be "nasty" - the solution is to stop usingthem
and use the gnome equivalents that are colormap friendly and aware that
we have control over in gnome....

->  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.

You are perfectly correct.. but the fact is people are getting fatsre
and faster machines wiht more ram and better gfx cards... PII-300 cpus'
wil be at $200US by july... that makes them ultra-cheap for
consumers... Yes gnoem will run on what I shall now call "legacy 8bpp"
systems., but the display quality and results may nto be optimal.. I am
just sayign we have alerady made some efforts in makign colormap usage
"tame" inder 8bpp - Imlib has had this for over a year. I can't see
that there is much mroe we can really do - in practical terms. Yes we
coudl come up with ultra-complex powerful colormap allocation schemes
with macthed entires liek you say and have these colromaps change
between apps etc. etc. - but this means a fair bit of work for little
gain - I woudl rather spend my time on features and applictaions
themselves than trying to support hardware that ina few years will be
rare and unused... It will work.. but not necessarily in the most
beautiful fashion... it's alerady a lot better than most other colro
management systems for X...

->  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
->  
->  

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com       /\___ /\ ___/||\___ ____/|/\___  raster@redhat.com
Carsten Haitzler           | _ //__\\ __||_ __\\ ___|| _ /  Red Hat Advanced
218/21 Conner Drive        || // __ \\_ \ | |   \ _/_|| /   Development Labs
Chapel Hill NC 27514 USA   ||\\\/  \//__/ |_|   /___/||\\   919 547 0012 ext 282
+1 (919) 929 9443, 801 4392   For pure Enlightenmenthttp://www.rasterman.com/