Re: Palette hogging

[raster redhat com]

On 26 Mar, David Kastrup shouted:
->  
->  Hi!
->  
->  I've leafed through the GNOME pages and some backlogs of the list, and
->  have looked at several screen dumps and so on, and I noticed that
->  GNOME looks very spiffy.
->  
->  I got a problem with that.
->  
->  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.
->  
->  For such setups, I propose that the desktop can be forced to restrict
->  all its decorations etc. to 16 colours (the basic CGA colours).  This
->  would imply colour coercion or dithering having to happen on more
->  fancy decorations.  For smooth borders, I think coercion to closest
->  available colour would be the thing.

have you actually RUN any parts of gnome? :) 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.

->  Of course, if a decoration can have an own idea about how to restrict
->  itself to such a basic colour set, it probably should be allowed to
->  use that 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.

->  Why, one could even try to select the actual colour maps as an average
->  weighted with the inverse distance to the cursor, so as to have
->  colours be the most accurate around the cursor.  This technique could
->  even be applied within a single image.  Just think about the visual
->  effect when doing pointer movements, specifically if colours are
->  really chosen badly matched in the first place.  Then you get one isle
->  of sanity centered around the cursor which gets increasingly strange
->  to the outside.

too complex - too much trouble. use the simpler Colrocontext or Imlbi
colr manaegemnt above. It is not worht the effort to do all of that.
8bpp wil be obsolete pretty soon. fewer and fewre people run in 8bpp -
there is alraady a reasonable color management system available. the
colrocontext ANd imlib colro stuf fis availabel to ALL gnome apps (as
imlib is initialised for every app already).

->  Ok, ok, forget about the last paragraph above.  But thinking of the
->  effects an overdecorated desktop might have on 8-bit displays is
->  important, I think.  I'd still like to start a reasonable xv or other
->  things with individual palette renderings without having to revert to
->  eye-jarring palette switching appeareances just because of a fancy
->  desktop.

no - how abotu uising electriceyes in gnome..a gnome image
viewer/browser that conforms to gnome's colro handlign specs.. :) xv is
nasty on palette usage sometimes.. netscape is ALWAYS nasty... (when
source is out someone REALLy needs to tame netscape's color management)
As long as imlbi si used for creating images that generally are the
worst offenders when it comes to using colors, you can be pretty sure
your colormap will be decently lean. You can make the images look
better by increasing the size of imlib's palette. 9ie add more colors
to the palete in the imlib_config program)

->  Keep up the good work,
->  
->  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/