From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: alkibiades@gmx.de Newsgroups: gmane.emacs.devel Subject: Re: XPM via Lisp in the toolbar Date: Sun, 17 Nov 2002 13:30:12 +0100 Sender: emacs-devel-admin@gnu.org Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1037537310 5743 80.91.224.249 (17 Nov 2002 12:48:30 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 17 Nov 2002 12:48:30 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18DOqj-0001UV-00 for ; Sun, 17 Nov 2002 13:48:29 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18DP4Z-0002FU-00 for ; Sun, 17 Nov 2002 14:02:47 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 18DOqj-0000S5-00; Sun, 17 Nov 2002 07:48:29 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18DOeS-00049v-00 for emacs-devel@gnu.org; Sun, 17 Nov 2002 07:35:48 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18DOdv-0003wX-00 for emacs-devel@gnu.org; Sun, 17 Nov 2002 07:35:18 -0500 Original-Received: from mail.gmx.net ([213.165.65.60]) by monty-python.gnu.org with smtp (Exim 4.10) id 18DOdu-0003uT-00 for emacs-devel@gnu.org; Sun, 17 Nov 2002 07:35:14 -0500 Original-Received: (qmail 25312 invoked by uid 0); 17 Nov 2002 12:35:11 -0000 Original-Received: from dialin-145-254-195-103.arcor-ip.net (HELO HERMES) (145.254.195.103) by mail.gmx.net (mp004-rz3) with SMTP; 17 Nov 2002 12:35:11 -0000 X-Mailer: emacs 21.2.1 (via feedmail 11-beta-1 Q) Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Sun, 17 Nov 2002 02:15:55 -0500") X-Operating-System: GNU/Linux, built from scratch: http://www.linuxfromscratch.org/ X-Attribution: os X-Face: "HgH2sgK|bfH$;PiOJI6|qUCf.ve<51_Od(%ynHr?=>znn#~#oS>",F%B8&\vus),2AsPYb -n>PgddtGEn}s7kH?7kH{P_~vu?]OvVN^qD(L)>G^gDCl(U9n{:d>'DkilN!_K"eNzjrtI4Ya6;Td% IZGMbJ{lawG+'J>QXPZD&TwWU@^~A}f^zAb[Ru;CT(UA]c& User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-msvc-nt5.1.2600) 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:9493 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9493 Richard Stallman writes: > As long as the image is not _explicitly_ re-read from disk as in my > example and as long as the image descriptor is not garbage collected, > this should already be the case. Not even clearing the image cache (I > mean the built-in image cache) would cause a second conversion, > because the image descriptor contains all image data as a value of the > :data attribute. > > Are you sure that the same image is not likely to be read from disk > many times in an Emacs session? I don't know for certain, but I would > have expected that to be common. I don't know the C code behind that -- so please read the following with that reservatio mentalis. But as far as I understand the issue, it won't happen. AFAICS it is prevented on two stages: The Emacs Lisp Reference says about the image cache: ,---- | Emacs stores images in an image cache when it displays them, so it | can display them again more efficiently. It removes an image from the | cache when it hasn't been displayed for a specified period of time. | | When an image is looked up in the cache, its specification is | compared with cached image specifications using `equal'. This means | that all images with equal specifications share the same image in the | cache. `---- The variable `image-cache-eviction-delay' controls how long an image may remain in the image cache without being displayed. The default is 30 minutes. Normally -- that is: without xpm.el -- the image descriptor for an icon in the tool bar would look like this: (image :file "/some/path/search.xpm" :type xpm ... ) So if the icon was not displayed for 30 minutes and Emacs has to display it again, it would read "search.xpm" from the disk again. That is how I understand it. But with `xpm-create-image' hooked into `find-image' as a fall-back for XPMs the image descriptor looks like this: (image :data "P6 32 32 255 ... ..." :type pbm ... ) So as far as Emacs is concerned there is no file attached to the image anymore. The string after :data contains the whole information necessary to display the image. I don't know whether an image descriptor in `tool-bar-map' has any chance to get garbage collected. As long as this does not happen, there is no need to read the image from the disk again. To read the image from the disk again, it would need another explicit call to `find-image'. I wouldn't know where in the code this latter could take place, BTW. Oliver -- Oliver Scholz 27 Brumaire an 211 de la Révolution Taunusstr. 25 Liberté, Egalité, Fraternité! 60329 Frankfurt a. M. http://www.jungdemokratenhessen.de Tel. (069) 97 40 99 42 http://www.jdjl.org