Re: [patch] cache color info for remote X sessions [Was: Emacs 21/X11 generating unbelieveable network traffic]

[Jan D.]

> > In principle, yes.  But if Emacs runs on the default visual, it uses the
> > default colormap, otherwise, it creates its own.  It would not be nice
> > by an application to change the default colormap or one created by Emacs.
> >
> > It can happen, but I consider that a bug in the application that does
> > such a thing.
>
> My "default" colormap has never behaved in that way.  It just contains
> whichever colors have been requested by applications, i.e. it is changed
> by applications like ExMH, Netscape, Emacs, ...

You are right, I didn't read the question properly.  If an application
allocates a color not in the colormap and there are free cells, these
cells change.  But Emacs should not be using cells (i.e. pixels) that
it has freed.    I don't think it does, I'll check that.

> > > As someone whose colormap is full about 95% of the time, I can
> > > assure you that tose things happen ;-)
> >
> > What should happen is that when the colormap is full, a new one is
> > created and then the window manager switches colormap depending on
> > which application has the focus.
>
> I hate colormap switching.  I much prefer what happens with Emacs:
> when XAllocColor fails, Emacs looks for the nearest color in the map
> and uses it.  After all I generally don't care that much about the
> exact color.

If the exact color isn't important, and the nearest color is ok, that is
easier on the user.  But sometimes the exact color is important, and
then you have no choise but to do switching.  Anyway, in about a year
or two, we will all be running 16 or 24 bit color and this problem
goes away :-)

        Jan D.