From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Pittman Newsgroups: gmane.emacs.devel Subject: Re: What is the proper way to scale fringe-bitmaps for high-DPI displays? Date: Thu, 21 Mar 2019 11:43:51 +0000 Message-ID: References: <4be02093-6e31-bfde-7d11-5900c7e02668@gmail.com> <83pnqlsb8l.fsf@gnu.org> <59f034d0-3473-0a83-ccf6-1a6fe446964c@gmail.com> <83h8bxs53y.fsf@gnu.org> <83ftrhs3lu.fsf@gnu.org> <83ftrg6gxm.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000b09a330584994234" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="157084"; mail-complaints-to="usenet@blaine.gmane.org" Cc: =?UTF-8?Q?Cl=C3=A9ment_Pit=2DClaudel?= , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 21 12:50:44 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h6wDb-000eka-KB for ged-emacs-devel@m.gmane.org; Thu, 21 Mar 2019 12:50:43 +0100 Original-Received: from localhost ([127.0.0.1]:35455 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h6wDa-0005Mn-Eh for ged-emacs-devel@m.gmane.org; Thu, 21 Mar 2019 07:50:42 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:58271) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h6w7q-0002Ll-F5 for emacs-devel@gnu.org; Thu, 21 Mar 2019 07:44:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h6w7o-0002zi-Oj for emacs-devel@gnu.org; Thu, 21 Mar 2019 07:44:46 -0400 Original-Received: from mail-it1-x135.google.com ([2607:f8b0:4864:20::135]:50826) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h6w7n-0002va-U6 for emacs-devel@gnu.org; Thu, 21 Mar 2019 07:44:44 -0400 Original-Received: by mail-it1-x135.google.com with SMTP id m137so3769295ita.0 for ; Thu, 21 Mar 2019 04:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ak9IiafYi4fcA0wEuDujBVxLRiHDpgW7zvB9E7/tXjg=; b=opBtnRHOMqG3Cxaf+y4AJ2c2ZXe3UoD+tYaB0IrGCmSAdDXZ5obFDa5bFEobNHDzpD MfHb6FpoySYDRPGlMc/ZINqk+zGxQGZQxqnWsakCNCguy5IesLm0I7Scuso71xS+kJf2 2RFIxlO++eSCDNXjGpH2aDL+8kPWQpbrgjdXjkH3m0M44NYjotVrGd2Mi09k3s1g6ZDX um9HNPSQtabaI8X6e4DN1Zbwz2/VeB0ouBGhRLf3efvOXvv+WhLDe70Vdcgef4Pf3o4A vkZfGqboIpEp8IlZCyQskyd1NA819W+C0g64LM1Rjh8VOEWDo6JF744kfZRorr3/+y7G Vkhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ak9IiafYi4fcA0wEuDujBVxLRiHDpgW7zvB9E7/tXjg=; b=qsSeCyM59UUjK+ZEY32DpWPa/akCDj6qCWI6cGjq66YXMpOVcBT+MxjCa38AeRLS13 IMeJbyJ8d/1jnr+24LaYDYbjGlE4hmikFEqx6SvYXwu5leRijNIlEWwJjVpUoa/VNfKa ubVybu/wgwClJrfqtXCESNusjFZPv6Fqt8tV8ckwPM0c5QIxS9lPS+1YmSpvOjkYBcz3 j+fjVqDT6LezhkIS9MwqVqvPUVLi91JvWV6afPw+G5yBEUVChxSSXXA2AdW03ycnLCq3 1KhYRc0ydufcQrStIPDpWfAjWPCPAZnECNEaHxaArbCbxI1nzM0OkIuvPooC6swMTK4s G0zA== X-Gm-Message-State: APjAAAVouAE01M3ysEPkpRq9BgPMoEA/N99LyH+CybiRGK+oDM2j01gy KKkiKmeyOFHqwoSF+RKFy/dhqRI31icYk2YuqC3zLQ== X-Google-Smtp-Source: APXvYqw4oQqpJC3ePZv9VQSaz097uyIsGiPsYgtMzInByBuE/TwHyVdDMueG0VbtK0otyYiFvribZr3nKMLDBDqm1VQ= X-Received: by 2002:a24:b649:: with SMTP id d9mr2026447itj.18.1553168667249; Thu, 21 Mar 2019 04:44:27 -0700 (PDT) In-Reply-To: <83ftrg6gxm.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::135 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:234460 Archived-At: --000000000000b09a330584994234 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 21, 2019 at 3:32 AM Eli Zaretskii wrote: > > Cc: emacs-devel@gnu.org > > From: Cl=C3=A9ment Pit-Claudel > > Date: Wed, 20 Mar 2019 17:17:16 -0400 > > > > >> Oh, so Emacs' C code would scale the bitmaps? I expected the Lisp > code would do that. > > > > > > Fringes are displayed in C. Doing this in Lisp will produce > > > flickering, I'm afraid. > > > > I thought the C code would read the scaling factor and set the bitmap > accordingly just once, when creating overlays or applying text properties= . > > But you were saying that a frame can move from a high-DPI terminal to > a low-DPI one, which seems to mean we cannot compute that just once. > They can, at least on macOS, where that is entirely trivial to achieve by plugging an external (low DPI) monitor into a (high DPI) laptop with the panel open. You could even enjoy the fun situation where your frame is displaying half the window on each of them, so technically has two different and concurrent densities. > And besides, there are fringe bitmaps that we display regardless of > any overlays and text properties (e.g., truncation and continuation > indicators), which are displayed directly from C. > What you really want here is a resolution independent unit for specifying the size of the output, or a macOS-alike ability to give multiple resolution bitmaps and have the most appropriate selected by Emacs, yeah? Anyway, I'd certainly say that having the C code scale the bitmap is the most reasonable "no changes to anything else" solution =E2=80=93 macOS did = that during the early transition to those high density displays, and it worked out pretty well overall. (Though they have a rendering model vastly less tied to physical units than most things.) As a potentially useful aside in this context, HTML specifies that the "pixel" is a resolution-independent unit, and should probably approximate a 72 DPI display as the 1:1 logical:physical device. I mention this because applying similar logic in Emacs would give the closest approximation of what people have been trained to expect in other media. (Though the choice to not scale the content of the img tag... was not great.) --000000000000b09a330584994234 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Mar 21, 2019 at 3:32 AM Eli Zaret= skii <eliz@gnu.org> wrote:
> Cc: emac= s-devel@gnu.org
> From: Cl=C3=A9ment Pit-Claudel <cpitclaudel@gmail.com>
> Date: Wed, 20 Mar 2019 17:17:16 -0400
>
> >> Oh, so Emacs' C code would scale the bitmaps? I expected = the Lisp code would do that.
> >
> > Fringes are displayed in C.=C2=A0 Doing this in Lisp will produce=
> > flickering, I'm afraid.
>
> I thought the C code would read the scaling factor and set the bitmap = accordingly just once, when creating overlays or applying text properties.<= br>
But you were saying that a frame can move from a high-DPI terminal to
a low-DPI one, which seems to mean we cannot compute that just once.

They can, at least on macOS, where that is en= tirely trivial to achieve by plugging an external (low DPI) monitor into a = (high DPI) laptop with the panel open.=C2=A0 You could even enjoy the fun s= ituation where your frame is displaying half the window on each of them, so= technically has two different and concurrent densities.
=C2=A0
And besides, there are fringe bitmaps that we display regardless of
any overlays and text properties (e.g., truncation and continuation
indicators), which are displayed directly from C.

=
What you really want here is a resolution independent unit for s= pecifying the size of the output, or a macOS-alike ability to give multiple= resolution bitmaps and have the most appropriate selected by Emacs, yeah?= =C2=A0 Anyway, I'd certainly say that having the C code scale the bitma= p is the most reasonable "no changes to anything else" solution = =E2=80=93 macOS did that during the early transition to those high density = displays, and it worked out pretty well overall.=C2=A0 (Though they have a = rendering model vastly less tied to physical units than most things.)
=

As a potentially useful aside in this context, HTML spe= cifies that the "pixel" is a resolution-independent unit, and sho= uld probably approximate a 72 DPI display as the 1:1 logical:physical devic= e.=C2=A0 I mention this because applying similar logic in Emacs would give = the closest approximation of what people have been trained to expect in oth= er media.=C2=A0 (Though the choice to not scale the content of the img tag.= .. was not great.)
--000000000000b09a330584994234--