Re: styles and writeable colormaps

[Dean Skuldt <skuldt mr radiology wisc edu>]

On 15 Nov 1999, Owen Taylor wrote:
> 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.)

Thanks for your response, Owen.  I had a look at the curves dialog in the
GIMP.  I was running it at the host (not remotely), and the re-rendering
it did after manipulating the curve for a 256x256 jpg image took rather
long - too long for my application's needs.  I probably didn't describe my
application very well before.  But in the context of the GIMP, for
instance, I would want to see the image colors change WHILE the curve is
being modified, as opposed to seeing the image change only after the user
is done modifying the curve. 

Although the delay of re-rendering is small for a single re-rendering in
the GIMP, these delays would stack up very quickly and cause a very large
delay if it were implemented in order that image changes would occur
immediately after curve manipulation.  Colormap manipulation appears to be
the only way to make this type of implementation work.  

> The way GTK+ does styles simply does not allow you to choose the
> pixel values that are used for particular values.
 
Yes, but it seems that it does allow you to choose the COLOR that is to be
used for foreground, background, etc.  If the writeable colormap has the
corresponding colors, shouldn't it be possible to be sure that the
foreground, background, etc. use these reserved colors in the colormap?  

I notice that a GtkStyle has a private GdkColormap field.  Perhaps by
getting the default style using get_default_style() and copying it, this
copied style is attached to the default colormap, and not my writeable
colormap.  

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

I began my project by using the RGB functions and loved the fact that I
didn't need to think about colormaps at all, but it just wasn't fast
enough. 

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

I agree, but it becomes significant when they are queued up many times. 
The delay is not as large as scaling and re-drawing, but it's still too
large. 

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

I'm with you for sure.  However, it seems that in order for this to work I
may need to play with the colormap.  We are using only UNIX machines, and
all of them support pseudocolor, even if the default is truecolor. 
Colormap flashing when switching between applications is something we're
willing to live with as long as window-level manipulation is fast. 

Thanks again for your insight, and I look forward to any additional advice
from you or others!

Dean