From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: image-size Date: Fri, 21 Jun 2013 09:46:04 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <837ghopy8a.fsf@gnu.org> <83zjukog7h.fsf@gnu.org> <83txksodgv.fsf@gnu.org> <83r4fwocqd.fsf@gnu.org> <83ppvgoaw9.fsf@gnu.org> <83mwqko9ge.fsf@gnu.org> <83k3loo66g.fsf@gnu.org> <2D9A8A78-829E-4AEC-BA3E-9409A1457053@swipnet.se> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1371775580 25202 80.91.229.3 (21 Jun 2013 00:46:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Jun 2013 00:46:20 +0000 (UTC) Cc: Lars Magne Ingebrigtsen , Eli Zaretskii , emacs-devel@gnu.org To: Jan =?ISO-8859-1?Q?Dj=E4rv?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 21 02:46:21 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UppUa-00042l-Up for ged-emacs-devel@m.gmane.org; Fri, 21 Jun 2013 02:46:21 +0200 Original-Received: from localhost ([::1]:50760 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UppUa-0005Ug-Ib for ged-emacs-devel@m.gmane.org; Thu, 20 Jun 2013 20:46:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43394) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UppUW-0005Lq-40 for emacs-devel@gnu.org; Thu, 20 Jun 2013 20:46:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UppUU-0003qi-E0 for emacs-devel@gnu.org; Thu, 20 Jun 2013 20:46:16 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:58177) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UppUS-0003p4-23; Thu, 20 Jun 2013 20:46:12 -0400 Original-Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id E3FE5C055D; Fri, 21 Jun 2013 09:46:04 +0900 (JST) In-Reply-To: <2D9A8A78-829E-4AEC-BA3E-9409A1457053@swipnet.se> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 133.82.132.2 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:160794 Archived-At: >>>>> On Thu, 20 Jun 2013 23:42:28 +0200, Jan Dj=E4rv = said: >> Of course there is no X stuff on Windows. But if you're running >> over X, lookup_image pushes data over X, for some reason or other. >> I have no idea what the reason might be, but perhaps somebody else >> does. > lookup_image calls img->type->load, and jpeg_load creates an X > pixmap (x_create_x_image_and_pixmap), i.e. on the X server, and > copies the image into the pixmap, i.e. transfers it to the server > (XPutImage). > The functions are totally different for X, W32 and NS, so how it > works on W32 is totally irrelevant for X and vice versa. > Loading the image just to determine the size is a huge overhead. > The image loading routines already know the image size before > sending it to the server (or the equivalent for W32 and NS), > otherwise they could not allocate the right size for the Pixmap. No > Imagemagic is needed to figure out the image size. Right. And as I mentioned in (*), a possible way to solve this problem is to defer the creation of Pixmap (server side resource) from XImage (client side resource) until the actual display happens (i.e., at prepare_image_for_display rather than lookup_image), so as to avoid unnecessary round trip of image data between the X11 server and client. *: http://lists.gnu.org/archive/html/emacs-devel/2010-09/msg01285.html On the Carbon port and its descendants, deferring the creation of image data for display (CGImage on OS X) from the raw pixel data (struct _XImage, a custom data structure made after X11) as above has been done for a long time. And I've never heard of a problem about that. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp