From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: [patch] cache color info for remote X sessions [Was: Emacs 21/X11 generating unbelieveable network traffic] Date: Mon, 7 Oct 2002 20:14:38 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200210071552.g97Fqoq25121@rum.cs.yale.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 (Apple Message framework v482) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1034014613 32372 127.0.0.1 (7 Oct 2002 18:16:53 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 7 Oct 2002 18:16:53 +0000 (UTC) Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17ycR1-0008Ps-00 for ; Mon, 07 Oct 2002 20:16:51 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17ydEC-0004fY-00 for ; Mon, 07 Oct 2002 21:07:40 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17ycQJ-0007eW-00; Mon, 07 Oct 2002 14:16:07 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17ycPL-0006qk-00 for emacs-devel@gnu.org; Mon, 07 Oct 2002 14:15:07 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17ycPJ-0006pw-00 for emacs-devel@gnu.org; Mon, 07 Oct 2002 14:15:07 -0400 Original-Received: from stubby.bodenonline.com ([193.201.16.94]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17ycPJ-0006nb-00 for emacs-devel@gnu.org; Mon, 07 Oct 2002 14:15:05 -0400 Original-Received: from pc35.bodenonline.com (IDENT:root@pc35.bodenonline.com [195.196.29.227] (may be forged)) by stubby.bodenonline.com (8.12.1/8.12.1) with ESMTP id g97IBEd8028573 for ; Mon, 7 Oct 2002 20:11:14 +0200 Original-To: emacs-devel@gnu.org In-Reply-To: <200210071552.g97Fqoq25121@rum.cs.yale.edu> X-Mailer: Apple Mail (2.482) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:8451 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:8451 > For AllocColor ? > How come ? Can't Emacs dealloc the color and re-allocate it again and > get a different result (because the color cell was allocated to some other > color in the mean time) ? 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. > 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. > Maybe we can flush the cache whenever Emacs deallocates a color > (that shouldn't happen too often, right?). BTW shouldn't we cache > DeAllocColor as well since the server normally keeps a counter > and each AllocColor should have a matching DeAllocColor ? True, a counter is needed for proper allocate/free operation. Jan D.