Re: styles and writeable colormaps

[Owen Taylor <otaylor redhat com>]

Dean Skuldt <skuldt@mr.radiology.wisc.edu> writes:

> Hello, 
> 
> I am writing an application which will use a writeable colormap (I use a
> PSEUDOCOLOR visual).  The application will display gray-scale images, and
> in order to window-level (change the contrast curve for) an image quickly
> the colormap will be modified.  I chose to use colormap modification
> instead of scaling and redrawing the image for every change of the
> contrast curve, which is very time-consuming.  By drawing the image only
> once, and then modifying the colormap when windowing and leveling, things
> are speedy.  
> 
> I allocate 256 colors in this writeable colormap.  I reserve the top 5
> colors for window and menu foregrounds, backgrounds, and text.  The other
> 251 colors are the gray-scale colors which are changed during
> window-leveling.  

Well, my honest response is:

 "Using writeable colormaps is a 1988 trick. This is 1999."

You cannot write a portable application that does so because the vast
majority of users will be using TrueColor displays.

And re-rendering, if done efficiently, is pretty fast. (Try adjusting
the settings in ee or changing the curves dialog in the GIMP.)

> Creating the colormap, and modifying the colormap is no problem.  However,
> I have been unable to force the foreground, background, and text of
> widgets to use the reserved colors in my colormap.  I try to do so by
> copying the default style, setting the colors in this new style, and
> pushing this new style before creating the widgets.  (code below)  I don't
> understand how to get the foreground, background and text to use these
> reserved colors. 

The way GTK+ does styles simply does not allow you to choose the
pixel values that are used for particular values.

The goal (and in most cases the practice) of the way we use colors
in GTK (as opposed to GDK) is that you set the RGB values and GTK+
takes care of allocating colors for you.

> Also, part of what makes my colormap manipulation so speedy is my use of
> gdk_colormap_change.  In one function call, all 251 colors can be
> modified.  The gnome website's gdk reference documentation indicates that
> this function is obsolete.  If I don't use this function, but use 251
> calls to gdk_color_change, things are very slow.  Can anyone tell me if
> gdk_colormap_change will really be made obsolete?  

Are you running over a remote link? Even there it is hard to imagine
that 251 calls to XStoreColor could take any significant amount of
time, since there are no round-trips involved.

The reason why gdk_colormap_change() is marked as obsolete is, beyond
the fact that writeable colormaps are obsolete, because
its API is completely broken. It only allows for change the
_first_ n colors in the colormap, and in order to use it, you need
to modify the contents of the GdkColormap structure. 

(It is a general rule that while GDK and GTK+ structures may
have publically readable fields, they never have publically 
writeable fields.)

So, no, I have no intention of supporting this call, though unless
there is a good reason, it probably won't be removed soon.

I'm sorry if this isn't a very helpful reply... I'm very much
interested in seeing GTK+ move away from such low-level hardware
dependent-tricks as changing colormaps, and to visual-independent,
portable code such as GdkRGB.

(It might be interesting if GdkRGB had the ability to render
through color-lookup-curves for the various components - that
could be a reasonably fast way of handling this kind of 
situation.)

Regards,
                                        Owen