From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: image scaling Date: Fri, 22 Feb 2008 17:41:10 -0500 Message-ID: <87y79c1unt.fsf@stupidchicken.com> References: <87odaam9oy.fsf@stupidchicken.com> <8563wiaskc.fsf@lola.goethe.zz> <87lk5dr3kf.fsf@stupidchicken.com> <85wsox8m9t.fsf@lola.goethe.zz> <87mypska6r.fsf@stupidchicken.com> <85myps8xrm.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1203720172 13552 80.91.229.12 (22 Feb 2008 22:42:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Feb 2008 22:42:52 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 22 23:43:16 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JSgbq-0001E3-Rc for ged-emacs-devel@m.gmane.org; Fri, 22 Feb 2008 23:43:15 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JSgbL-0006SN-Ck for ged-emacs-devel@m.gmane.org; Fri, 22 Feb 2008 17:42:43 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JSgbH-0006Ro-A4 for emacs-devel@gnu.org; Fri, 22 Feb 2008 17:42:39 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JSgbD-0006P0-PF for emacs-devel@gnu.org; Fri, 22 Feb 2008 17:42:39 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JSgbD-0006Om-Jf for emacs-devel@gnu.org; Fri, 22 Feb 2008 17:42:35 -0500 Original-Received: from cyd.mit.edu ([18.115.2.24]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JSgbA-0006dj-8z; Fri, 22 Feb 2008 17:42:32 -0500 Original-Received: by cyd.mit.edu (Postfix, from userid 1000) id EF88A4E3FB; Fri, 22 Feb 2008 17:41:10 -0500 (EST) In-Reply-To: <85myps8xrm.fsf@lola.goethe.zz> (David Kastrup's message of "Fri\, 22 Feb 2008 22\:52\:13 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.91 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:90032 Archived-At: David Kastrup writes: >>>> but it's simple enough to understand and work on; and I don't know of >>>> any performance problem in the way Emacs handles image pixmaps. >>> >>> You must be kidding. We have an image cache exactly because Emacs can't >>> handle images close to reasonably efficiently. >> >> Don't other programs use caches for images? > > XEmacs, for example, does not have the equivalent, and works fine > (actually quite faster than Emacs) when using preview-latex. > > The point is that when the image data is loaded into memory, Emacs still > can't display it fast. It converts it with a painfully slow conversion > chain called for every pixel into a pixmap and caches that. Considering > that the binary data is pretty much identical a pixmap to start with > (maybe modulo a gamma correction lookup table), this is somewhat > ridiculous. The code paths are so muddled, however, that it is not easy > to rip this out. > > Have you actually looked at the code? I'm fairly familiar with the code. If Emacs can't quickly display images that are already loaded into memory, it's not clear to me that the problem lies in the image.c code rather than redisplay. Could you elucidate? When you say the image is already "loaded into memory", do you mean that the image is supplied using a Lisp string representing binary data (i.e., passing a DATA-P argument to create-image), or are you simply referring to time Emacs takes to run the png_load function (i.e., from calling the libpng functions parsing the file until Emacs finishes populating and caching the pixmaps)?