From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.devel Subject: Re: exposing x_get_scale_factor into elisp level Date: Wed, 24 Mar 2021 21:32:30 -0400 Message-ID: <2C3F94EF-5A2D-4AB9-8B3F-0E999623ACA2@gmail.com> References: Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_DC313859-4BB5-4BED-9C66-5392AA91C30F" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39959"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Alan Third , emacs-devel To: Evgeny Zajcev Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Mar 25 02:33:37 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lPEsQ-000AHA-US for ged-emacs-devel@m.gmane-mx.org; Thu, 25 Mar 2021 02:33:35 +0100 Original-Received: from localhost ([::1]:41782 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lPEsP-000758-Pg for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Mar 2021 21:33:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48896) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lPErT-0006YW-8S for emacs-devel@gnu.org; Wed, 24 Mar 2021 21:32:35 -0400 Original-Received: from mail-qt1-x831.google.com ([2607:f8b0:4864:20::831]:39565) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lPErR-0006vU-D9 for emacs-devel@gnu.org; Wed, 24 Mar 2021 21:32:34 -0400 Original-Received: by mail-qt1-x831.google.com with SMTP id g24so594124qts.6 for ; Wed, 24 Mar 2021 18:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=tMTZeTOH86z8SDsvfLxKfAYCS6qGJQRn2jnEmxkVSBA=; b=OOxnssPpwY18w18Jb4VRhE57kp/7StVkX3a6x0kVu+xYpFBZAnz48zJuxxFXa98gIz Nu6qqg6LRWM3IOqImkup8FCq2kv9nuGkMc9K0FMAJApDk0+9kosFvmFxkv38PAyh5BM/ 82tFDx21rMhRGnbZpCSoN2vN3sX8etw+d2Zegdsgug0+TtGqyXoUW0Mz0MXqYwUBDbPk CFQg9z9HZsQeGBmStehvlq+7ecRrReM9OszNa693UnCZggT1GMHaF419A7sMl9OBYvLa dFrgtBqKQ7jQj3zzZKmOi8nua4aGJ1kUHv5rArqSwTGO9sVg9ktrdHMloLjL95g1m4P+ wKzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=tMTZeTOH86z8SDsvfLxKfAYCS6qGJQRn2jnEmxkVSBA=; b=nUltS22+K6jeh+IJ/BgfkLq4x3/3uzqCYEavnExjAc9LbBdq9Y1INA9BKDBbAyoYKx UlrLg06LlVhUuaGc0eH2D6jvX6WKmqOgxRQt351vUrIHzuW63/P3ksl7FbflAIPUN00M A4VIT0ynTWN3rc1qCVTy/Pk2828BhUL3OG7y51vNQofXzQ8fE+8oqlR+S+nlaZbr5xfh TXI4jFANP81IZh3EG+Bzjeq9rIOnO4qtS4OFZ65AhtDeKhNukW5/pAaT1a3gfSoKQ3XG jTBJuU/7R1RqYz7nt5fu0gpSDVhOu+sxEkLRFQC4VnWR+t0bPVLzLJAkoXAsUKoB27+r uhow== X-Gm-Message-State: AOAM5320+AVSMc+OJsiVmzOwYJEHAXAbGKfCneiZTXkc3xj8BSR+fsLs cwJSp7c4M9Ry62l1XHIBye4= X-Google-Smtp-Source: ABdhPJyzgu4D7XGYEnBguV8HYikYLN1NaP4q13EP6GDx8jyxQJBmd3JGyMVhzgf2Tyrn43VfdjupBg== X-Received: by 2002:ac8:4a19:: with SMTP id x25mr5695373qtq.271.1616635951808; Wed, 24 Mar 2021 18:32:31 -0700 (PDT) Original-Received: from ?IPv6:2601:98a:4200:9210:5123:41b4:7849:14f0? ([2601:98a:4200:9210:5123:41b4:7849:14f0]) by smtp.gmail.com with ESMTPSA id n77sm3159174qkn.128.2021.03.24.18.32.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Mar 2021 18:32:31 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.3654.60.0.2.21) Received-SPF: pass client-ip=2607:f8b0:4864:20::831; envelope-from=casouri@gmail.com; helo=mail-qt1-x831.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:266997 Archived-At: --Apple-Mail=_DC313859-4BB5-4BED-9C66-5392AA91C30F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 24, 2021, at 5:20 PM, Evgeny Zajcev wrote: >=20 >=20 >=20 > =D1=81=D1=80, 24 =D0=BC=D0=B0=D1=80. 2021 =D0=B3. =D0=B2 23:27, Alan = Third >: > On Mon, Mar 22, 2021 at 02:07:41AM +0300, Evgeny Zajcev wrote: > > HiDPI is very common nowadays. Internally Emacs has decent support = for > > HiDPI displays. However elisp code, that generates non-svg images = don't > > have any idea that logical pixel may differ from physical one, = resulting in > > generating images in low resolution on HiDPI displays. > >=20 > > Emacs internally has a notion about HiDPI displays, such as > > `x_get_scale_factor`, maybe expose this function to elisp level, so > > packages may utilize it to generate images in highres? >=20 > On NS platforms (macOS and GNUstep) and, I believe, native GTK the > scale factor is how much the TOOLKIT scales things up for display. >=20 > The problem we hit on MacOS is that line height is reported in logical = pixels, and we generate PNG images using that line height value. This = results in poor PNG quality since the physical pixel is x4 times larger. = Now we use heavy heuristics to workaround this, it will be great to = have some general approach as Emacs do internally (`x_get_scale_factor') >=20 > Unfortunately, we can't use SVG instead of PNG at the moment >=20 Meanwhile, maybe you can just generate a 2x png image and scale it down, = regardless of the true scale factor? Yuan= --Apple-Mail=_DC313859-4BB5-4BED-9C66-5392AA91C30F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 24, 2021, at 5:20 PM, Evgeny Zajcev <lg.zevlg@gmail.com> = wrote:



=D1=81=D1=80= , 24 =D0=BC=D0=B0=D1=80. 2021 =D0=B3. =D0=B2 23:27, Alan Third <alan@idiocy.org>:
On Mon, Mar = 22, 2021 at 02:07:41AM +0300, Evgeny Zajcev wrote:
> = HiDPI is very common nowadays.  Internally Emacs has decent support = for
> HiDPI displays.  However elisp code, that = generates non-svg images don't
> have any idea that = logical pixel may differ from physical one, resulting in
> generating images in low resolution on HiDPI = displays.
> 
> Emacs = internally has a notion about HiDPI displays, such as
> = `x_get_scale_factor`, maybe expose this function to elisp level, so
> packages may utilize it to generate images in = highres?

On NS platforms (macOS and = GNUstep) and, I believe, native GTK the
scale factor is = how much the TOOLKIT scales things up for display.

The problem we hit on MacOS is that line height is reported = in logical pixels, and we generate PNG images using that line height = value.  This results in poor PNG quality since the physical pixel = is x4 times larger.  Now we use heavy heuristics to workaround = this, it will be great to have some general approach as Emacs do = internally (`x_get_scale_factor')

Unfortunately, we can't use SVG instead = of PNG at the moment


Meanwhile, maybe you can just generate a 2x png = image and scale it down, regardless of the true scale = factor?

Yuan
= --Apple-Mail=_DC313859-4BB5-4BED-9C66-5392AA91C30F--