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: Testing native image scaling Date: Sat, 19 Jan 2019 21:45:43 +0000 Message-ID: <20190119214543.GA13967@breton.holly.idiocy.org> References: <83fttpat8p.fsf@gnu.org> NNTP-Posting-Host: ciao.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ciao.gmane.org 1547934355 115610 195.159.176.228 (19 Jan 2019 21:45:55 GMT) X-Complaints-To: usenet@ciao.gmane.org NNTP-Posting-Date: Sat, 19 Jan 2019 21:45:55 +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 Sat Jan 19 22:45:48 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1gkyR2-000TzC-GX for ged-emacs-devel@m.gmane.org; Sat, 19 Jan 2019 22:45:48 +0100 Original-Received: from localhost ([127.0.0.1]:60189 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gkyRB-000766-Ee for ged-emacs-devel@m.gmane.org; Sat, 19 Jan 2019 16:45:57 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:38731) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gkyR5-00075p-2M for emacs-devel@gnu.org; Sat, 19 Jan 2019 16:45:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gkyR4-0003ZE-5z for emacs-devel@gnu.org; Sat, 19 Jan 2019 16:45:51 -0500 Original-Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]:34363) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gkyR2-0003X7-Qf; Sat, 19 Jan 2019 16:45:49 -0500 Original-Received: by mail-wr1-x42f.google.com with SMTP id j2so19186698wrw.1; Sat, 19 Jan 2019 13:45:48 -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=Y1vAWyed+u2zNwrcK1mrckNxY56tDCHvrrXagKZ2X+4=; b=sL1xp/uUdP95aA2aQhODnr3jib4qvQ6hjEImxRausxBixWonaTxszBnrWtjkEXwe0/ FEPJFcHfl0mMEYjVDLUnZ3Fw1sve9n55YBiIfr2tg4lqi0nRUqqtWCL8//zB9Du/2oQf Jm17cXPy+wp37HPzcOiCgNOKbMcs5NVNF0hsWdtSoLzsCsRe44cOv/R9O6NqTTuUWFQW nFTHA1fo3BHMyPVVrXXvZjmH7u5qejIyyEdZb0NbDfN8U7pTI5EmR4h5QEwHD+TjQsgt 6MPvlDgSLa7QKAuXGJrOIEagGXm7g3AAJpXFvY/h7PQ7rX4ALw74emgimfHO//u/pnGe WNgw== 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=Y1vAWyed+u2zNwrcK1mrckNxY56tDCHvrrXagKZ2X+4=; b=t6AEv2RYRDWOUBsW3LNraao4A9Zu3rEK2BI845PJozzhqK8mRDBTYDLWArDIULKQuh Ur2/Q3yi0zcXurccvhNZIBiR7ugpgT25cnoIOrxqma6orAaGQrd0eroaBQUuHZktB02Z zvUNo36Ck+aX1GHZOXFVOofejyrEN2F/YDcuh08PJJOLzv4Htg2xkcYvSsmuNrN/tuVy megrdJMO/+lLQww2ODOYvrrr/ck4u17lQrrZzYgLKcrp0a1QXxUFcaHT1/+t75R6k40Q 2ka3zTrabNiMtvC65S42eSyMl0KFDeowWj/+yQr3ME1OcerG5qxZRsgnvoXQ17iPKUT6 ckgw== X-Gm-Message-State: AJcUukcc4cKCGEm30P7WpKeQxXmlJCkWuksGATB2eDqvYVK8lnGG0X6Y KfZtFp8xETxvpz13jywZ9FYHvQVO X-Google-Smtp-Source: ALg8bN4zCz2rZmeX64n4TSTNetU9E78yJpksjrWXBimpmcQIAhvpJi9XIs4YihB5z345lIa2DmyahA== X-Received: by 2002:adf:b6a1:: with SMTP id j33mr21749414wre.55.1547934346783; Sat, 19 Jan 2019 13:45:46 -0800 (PST) Original-Received: from breton.holly.idiocy.org (ip6-2001-08b0-03f8-8129-5c92-e7e5-6fdc-0783.holly.idiocy.org. [2001:8b0:3f8:8129:5c92:e7e5:6fdc:783]) by smtp.gmail.com with ESMTPSA id t4sm59235876wrb.64.2019.01.19.13.45.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Jan 2019 13:45:45 -0800 (PST) Content-Disposition: inline In-Reply-To: <83fttpat8p.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::42f 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:232501 Archived-At: On Sat, Jan 19, 2019 at 11:31:34AM +0200, Eli Zaretskii wrote: > Alan, could you please tell how you tested native image scaling with > the XRENDER extension, and perhaps show some Lisp or existing commands > you used for that? E.g., did the features in thumbs.el work for you > in a build without Imagemagick? I just used a fairly simple series of commands like this: (setq i (create-image "~/image.png" nil nil :scale 0.5)) (insert-image i) (setq ii (create-image "~/image.png" nil nil :scale 0.5)) (insert "\n") (insert-image ii) (insert "\n") (insert "x") (insert-image i) (insert "x") (insert "\n") (setq i (create-image "~/image.png" nil nil :scale 0.25 :margin 10 :relief 10)) (insert-image i) (insert "x") (insert "\n") (setq i (create-image "~/image.png" nil nil :width 25)) (insert-image i) I was testing with animated gifs at one stage, which is why I was using setq. I also found various files using C-x C-f. It look like thumbs.el uses ImageMagick’s convert program directly, so it won’t be affected by native scaling. > I tried to implement this for MS-Windows, but I guess my understanding > of the internal workings of this is incomplete/incorrect, or my code > is buggy (or both), because I don't seem to be able to cause Emacs to > exercise the code when the original image's size and the size > requested by scaling differ. For example, I thought that when scaling > is requested, x_set_image_size should be called and compute image > dimensions different from the original img->height and img->width, but > I seem to be unable to see this. What am I missing? Could you > perhaps describe the flow of calls when, e.g., the user types '+' on > an image in image-mode, and Emacs scales the image at point? I think you understand this right. x_set_image_size calculates the new sizes, does the conversion, and writes those new sizes back into struct image, over‐writing the original sizes. For NS it also asks the NSImage back‐end to scale the image using ns_image_set_size, which in effect does the actual scaling. For XRender it sets up an affine transformation matrix, and applies it to img->picture, which also in effect does the actual scaling. The compositing functions in nsterm.m and xterm.c don’t need to know the original image size, just the new size, and NSImage/XRender handles the rest. There are only two potential problems I can see: 1. If you’re building with ImageMagick, then when you hit + in image-mode it automatically reverts to ImageMagick as a back end. In that case x_set_image_size won’t do anything since ImageMagick will have already resized the image. If you insert images directly into a buffer like I did in the script above then ImageMagick will never be used unless you explicitly request it. 2. If you missed the fact that img->width/height are set within #ifdef/#endif blocks. That is due to the requirement of checking img->picture for XRender, although there are plenty of other ways to handle it. > P.S. Incidentally, image-scaling-p is called in image.el also in > context where we want to know whether an image can be rotated by 90 > degrees, and native scaling doesn't support that, does it? That’s correct. I should have created new separate functions for testing rotation and scaling. We could use XRender to rotate images if we really wanted to, and the NS port already supports it. -- Alan Third