emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch] cache color info for remote X sessions [Was: Emacs 21/X11 ge


From: Jan D.
Subject: Re: [patch] cache color info for remote X sessions [Was: Emacs 21/X11 generating unbelieveable network traffic]
Date: Tue, 8 Oct 2002 07:16:51 +0200

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]