From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Third Newsgroups: gmane.emacs.devel Subject: Re: Linking to ImageMagick by default Date: Sun, 30 Dec 2018 12:47:59 +0000 Message-ID: <20181230124759.GA77761@breton.holly.idiocy.org> References: <20181205223901.GA5543@breton.holly.idiocy.org> <20181208183810.GA2465@breton.holly.idiocy.org> <20181210220944.GA4793@breton.holly.idiocy.org> <20181219160308.GA43504@breton.holly.idiocy.org> <83efadcw3j.fsf@gnu.org> <20181227131105.GA18792@breton.holly.idiocy.org> <834lay6pe4.fsf@gnu.org> <20181228212115.GA59461@breton.holly.idiocy.org> <83pntk6cte.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1546173969 10894 195.159.176.226 (30 Dec 2018 12:46:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 30 Dec 2018 12:46:09 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 30 13:46:05 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gdaTk-0002ih-Nn for ged-emacs-devel@m.gmane.org; Sun, 30 Dec 2018 13:46:04 +0100 Original-Received: from localhost ([127.0.0.1]:44182 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gdaVr-0001tM-71 for ged-emacs-devel@m.gmane.org; Sun, 30 Dec 2018 07:48:15 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:34170) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gdaVi-0001sv-Al for emacs-devel@gnu.org; Sun, 30 Dec 2018 07:48:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gdaVh-0004pA-CE for emacs-devel@gnu.org; Sun, 30 Dec 2018 07:48:06 -0500 Original-Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]:45364) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gdaVf-0004nU-Ub; Sun, 30 Dec 2018 07:48:04 -0500 Original-Received: by mail-wr1-x436.google.com with SMTP id t6so24623497wrr.12; Sun, 30 Dec 2018 04:48:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=fedrBDpw/Py4+PoLJPfevTQjhR8bgCYMZH1u9CUOTes=; b=onM8gmZQ5KAwP/e5wIYU0xTS9PpFKY7kGCOYBMaUrKL7SkfCl05WL4WYwzrl8C+9+p NpGKBDWLXohn1WpHPsBzQxwj86/RUKhFnCiPV+8WrU9JFhVvdiM1wJvwcrKbsCbKUilA fNYpk24eQPLqwRRnAnHN9GlcE/zIFR00XRCuAc8yM1jFIbugH6LvKoE74/O4LFqIkgYx BuzL/IwfldoC0BvQ4TFQhdEFPib2SAQKiDK2bvckzed3RG9DsFzjWGxdCKC6hTT5DgVN h6oeMrMA3apRro2T2ok+Rm96ColNfPE3qNw4F3xTiqb8S7QtP3Ns8nX2g1nOniTKiNDF zJcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=fedrBDpw/Py4+PoLJPfevTQjhR8bgCYMZH1u9CUOTes=; b=EX6mWXb4vbOQsDmzxC5uZeGiQ2zgeYm51SyVITFKeb/Ipp8HAQ0/sFeINvA1YbMUWz OjJ0SUQ20mFge8VCm69UK0lbZmNT16uQE11PJltlfgXp6higJS5o2LNb9B2Bkwiw0HID iRxNfgOZdoAGuzRdVTRtKaztWb+b/i4QderBXHifXPY6AHLU6KxnidFAw6EL/RNY8t+P wkl7YAP09IVbkUVvyinw4FooLjiGQuLImDQC1Ja6TrRQKD4/qHbsw39ZsiRHI64ta65s 3wx+jq+Bh4Up+HY7xKQqZa/Sym/12i2qqffXR0ec1gYYFuqcK1/KadJ6MGSEFc9/fIlr VHmg== X-Gm-Message-State: AJcUukeX90YHjroRkxTJKWycOMCnK7nFLKdq67IcYUFK11cl/TFG1WbT OmMmea4UhJhXHjOi7s4SMnAM3cPq19I= X-Google-Smtp-Source: ALg8bN78CNbcHHHay737VwK2ZRnP4UGQpNbRI4iwl7TyotZ6sqyfEIYC4e9jFLDTRRdnKN42FyxgVA== X-Received: by 2002:a5d:504f:: with SMTP id h15mr30850370wrt.83.1546174082134; Sun, 30 Dec 2018 04:48:02 -0800 (PST) Original-Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-51da-133a-2664-eea3.holly.idiocy.org. [2001:8b0:3f8:8129:51da:133a:2664:eea3]) by smtp.gmail.com with ESMTPSA id v8sm46518340wrq.53.2018.12.30.04.48.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Dec 2018 04:48:01 -0800 (PST) Content-Disposition: inline In-Reply-To: <83pntk6cte.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::436 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:232045 Archived-At: On Sat, Dec 29, 2018 at 08:56:29AM +0200, Eli Zaretskii wrote: > > Date: Fri, 28 Dec 2018 21:21:15 +0000 > > From: Alan Third > > Cc: emacs-devel@gnu.org > > > > > One reason to avoid this new struct is that it makes struct glyph, > > > struct glyph_string, and struct it larger, which will make the display > > > code slower, especially if the larger structs cause spilling of CPU > > > caches. The display engine shuffles these structures to and fro in > > > many places, so they should be as small as possible. > > > > I added this struct to separate the image pixel data from the size > > information. The idea is to avoid loading and holding multiple copies > > of the same image in RAM when we want to display at different sizes. > > I think with my suggestion you will still hold only one copy: the last > one whose size was calculated. AFAIU, the same happens with your > implementation, you just hold the last size separately. If someone were to do something like this (insert-image (create-image "file.png" nil nil :width 100)) (insert-image (create-image "file.png" nil nil :width 200)) We need to be able to differentiate between the two images. The current way is just to load file.png twice, and hold the two different sized images separately. My method loads it once, then makes redisplay work out the sizes before it displays them. I believe your method loads it once, then updates the image struct on the fly between the two sizes as and when it needs them. I’m not sure how that would work. To be perfectly honest, I’m not entirely sold on the idea that we need to hold only one copy, it just seems like a waste to load and store the image multiple times. But, Emacs is not a graphics application and it seems unlikely that displaying multiple, slightly different copies of an image is a major use‐case. I may just scrap all this and go back to the basics and provide a resizing system that just loads and stores each image separately, like the current setup. If we want we can revisit the caching and so on later. (A side note: I believe the NS toolkits provide transparent image caching anyway, so this doesn’t really matter there.) > > I’m not sure how to check whether the image needs resizing without > > doing the lookups for :width, :height, :max-width, etc. > > Maybe I'm misreading the code, but it looks to me you only need > :scale, :width, and :height. Am I missing something? As Juri also pointed out it’s often preferred to set :max-width or :max-height purely to make sure an image fits in a certain space without having to calculate the required width and height to maintain the aspect ratio and so on. > > At the moment it’s avoided simply by not using :type imagemagick. > > If the caller might know whether resizing is needed, perhaps we should > pass an extra flag argument to that effect. Perhaps the best solution is to parse the lisp image spec in a different way, so it only runs through the plist once and notes down the settings, instead of the current method of running through it every time? We’d still have to do some size checking, but I suspect the time saved on parsing the image spec would be far larger than that. FWIW, the time spent throwing around pixel data is, as far as I can tell, far greater than the time spent parsing the spec and calculating the sizes. -- Alan Third