From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Yuri Khan Newsgroups: gmane.emacs.devel Subject: Re: What is the proper way to scale fringe-bitmaps for high-DPI displays? Date: Thu, 21 Mar 2019 20:33:33 +0700 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: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="78121"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Eli Zaretskii , =?UTF-8?Q?Cl=C3=A9ment_Pit=2DClaudel?= , emacs-devel To: Daniel Pittman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 21 14:34:50 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 1h6xqL-000KBz-OJ for ged-emacs-devel@m.gmane.org; Thu, 21 Mar 2019 14:34:49 +0100 Original-Received: from localhost ([127.0.0.1]:37335 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h6xqK-0003Nh-Bp for ged-emacs-devel@m.gmane.org; Thu, 21 Mar 2019 09:34:48 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55897) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h6xpd-0003Mp-0X for emacs-devel@gnu.org; Thu, 21 Mar 2019 09:34:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h6xpb-0003rv-79 for emacs-devel@gnu.org; Thu, 21 Mar 2019 09:34:04 -0400 Original-Received: from mail-ot1-x330.google.com ([2607:f8b0:4864:20::330]:35187) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h6xpO-0003S9-Tb; Thu, 21 Mar 2019 09:33:51 -0400 Original-Received: by mail-ot1-x330.google.com with SMTP id h7so5402595otm.2; Thu, 21 Mar 2019 06:33:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=vk9hxaGH0eDNqIRgFpz4cKsE/wjrCJjMG0TmdP+QtPM=; b=mqjg36QujQMz59+zgAJrhpHnw/Lhb0Vv+/wrVbrsJfywCbMcUYHtd+1nFvp+lhyvD5 8MZ8AKqA/cJ4zY0hQih3rSjhF5fp/LjizGfLaTwjejWq19P6KOmLu1wvEhW2e4J9zhoC hTHM/SzD8CMZDgpPrIjwmChmSaQPlv9eM5rW+EJUykPnoAWml8HcesD5XTNDILVC9jSV aRMmKVceX/tXNAkf43AcdhYG9VsttWnMnPx7ykdARXZyMwVISr5ThB/dsRAFBNBHWgzo SuX7qqFAvdCzkn5GHWfg/YD/A7M4fhscxgmSECr9n5ErGM40fr0dNIMSuuL6pNZaHO1p fdQw== 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:content-transfer-encoding; bh=vk9hxaGH0eDNqIRgFpz4cKsE/wjrCJjMG0TmdP+QtPM=; b=S0oeaV06wsmdKnu1j3wD+pp1eHdaCi62T5RGZWrcTmORmPgUIZC+D/lJgd1RDDs0Fo WL31G3WG/Zqzs6da8gBAE0sf4LfsfckdHIWK/VCkNxorYyI7kf7Gw4Zla/1CXVxvihX7 4r4nXFTYpv1Bh61v4DQhc8+iU28k2JpDqI+zphSWHI/TeFhQFgaCRJSkC1Enz6BANq43 Akhhrn/GvBfqi/ujjlFlH0XvM+cvXB8omaqX6v+bzCL8NMSTgChWIt6y94rnhONmSHLM Hw2hy2lXb++ngb4XXyfD4EMCU/0za+e3uKu+iz1JwnOW5haXE7w6Ayp141mfZO4M/MXU 69gA== X-Gm-Message-State: APjAAAVubRiX+kSZec4ZTTyl5C/VfqP+mLt9bfvlPM3a1gqqK8WUsXpn TMQQAk/tYQt3YrlguZkx+Gex2MipDESFwhp/nyI= X-Google-Smtp-Source: APXvYqwifOliQCYxFxQ5WrFiomfQGNOC+6IPA1Wg3Bwe3Ac9nICXjkDWE0YAi9eIyoEFFVpAAxrf4sYxhulV0TSm+UE= X-Received: by 2002:a9d:4e13:: with SMTP id p19mr2621449otf.120.1553175224904; Thu, 21 Mar 2019 06:33:44 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::330 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:234461 Archived-At: On Thu, Mar 21, 2019 at 6:50 PM Daniel Pittman wr= ote: >> 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 p= anel open. You could even enjoy the fun situation where your frame is disp= laying half the window on each of them, so technically has two different an= d concurrent densities. I hear GTK+/Wayland also has this ability. Never tried it though. GTK+/X is as far as I know constant DPI over the whole X display. > 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 resoluti= on bitmaps and have the most appropriate selected by Emacs, yeah? I can see the following options: * Migrate everything to SVG. Teach developers SVG is good, bitmaps are bad. Package developer provides a single vector image. Failure mode: developer is on a high DPI screen, makes a high-detail image, low DPI users complain =E2=80=9Cimage is blurry=E2=80=9D. * Keep bitmaps and upscale them for high DPI. Package developer provides a single bitmap image. Failure mode 1: Nearest neighbor upscaling looks ugly at non-integer factors. Failure mode 2: all other upscaling algorithms look ugly pretty much always. * Keep bitmaps and downscale them for low DPI. Package developer provides a single, fairly large bitmap image. Failure mode: small details get lost on low resolutions, image looks blurry. * Migrate to multi-resolution bitmaps. Package developer has to provide multiple bitmaps. Failure mode 1: Nobody knows what sizes they need. Failure mode 2: Some will only include one for the low DPI. This can be combined with up/downscaling, trading the corresponding failure modes around. > As a potentially useful aside in this context, HTML specifies that the "p= ixel" is a resolution-independent unit, and should probably approximate a 7= 2 DPI display as the 1:1 logical:physical device. Actually, the HTML pixel is specified as 1/96 of an inch.