From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Evgeny Zajcev Newsgroups: gmane.emacs.devel Subject: Re: exposing x_get_scale_factor into elisp level Date: Thu, 25 Mar 2021 00:20:09 +0300 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000db0b1605be4edd8f" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24633"; mail-complaints-to="usenet@ciao.gmane.io" To: Alan Third , Evgeny Zajcev , emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Mar 24 22:22:45 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 1lPAxf-0006EF-5y for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Mar 2021 22:22:43 +0100 Original-Received: from localhost ([::1]:57190 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lPAxe-0003K5-4J for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Mar 2021 17:22:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55640) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lPAva-0002FF-8j for emacs-devel@gnu.org; Wed, 24 Mar 2021 17:20:39 -0400 Original-Received: from mail-lf1-x136.google.com ([2a00:1450:4864:20::136]:37854) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lPAvU-0000jV-Su for emacs-devel@gnu.org; Wed, 24 Mar 2021 17:20:31 -0400 Original-Received: by mail-lf1-x136.google.com with SMTP id q29so33957391lfb.4 for ; Wed, 24 Mar 2021 14:20:23 -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; bh=3L62m1sZaP7K90SPTEzgIQSCvBcwg/bMpHa9KRyZXaM=; b=KnFQMJcMbPOFEkwDZDc/EpYwXADU+fV7IGwBQIc5JMMe0gVzOhbBmrfiSNMnzkmFL2 ANQb34ot4xd5IrdoJuF/sD97y6ybfEoez2UccsBrcw11viydLAXu5WM7Tkths38xehmh xo/Fcz6uWjznurz6tKq/2ItHjryiIl4rC+o9eXkEtcHqJwd8JkgRM2FWjngtCEKiTI// +gYe6X17ja6dexinEBMTAOFZKmWuEge3z3WAHXLM4ESqyC9fmbFb37pkfuEZjmvxTEyX PLkuezIMoRW+VFd0cH9wivbTEhjkzKt/XVWs6IzORtcQ4Y4aSJGYpd3U92K9aPrixGPZ C12Q== 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; bh=3L62m1sZaP7K90SPTEzgIQSCvBcwg/bMpHa9KRyZXaM=; b=e3xTm/JOTgEVzN1fG77mXNXY9XwrZTUEdoghChp8Crpr6Mu73S/1Vpwf7b4l36bC/s aPIkvZG8zq5/mSZQFmeOlGJwDVw9pfRxkMNcjsCYMjAObGhPVX2/ckU7etEIFOerV3nj T6CULeMtPqUo/GxeDRFDrwAZV8xLAuJabxvG2kd+dtuAQRUE1bJYcOXPX5mdBgAqiQzq vFFsqRM0RzbSK5+TDYBJmCXYx88Ml9i5MBMgeSe8zJJwVYnxFuvIEHTbe/eFRSPx5Yh7 D5hvRAlNoCWQM6hwWICdT8GMHI+hmnpnOcvujYQNjNOj39P7JsgMcTWq2ACUjCL7Dpph myYA== X-Gm-Message-State: AOAM533Ij8oysFLGMfOs5QlBtWt6tgzFHNg5mA+VhESVlS82IpinE48k hFi7ihievLd0wTChu7jHaEJZWrO5cDXP2Wq5rX0= X-Google-Smtp-Source: ABdhPJwVokoWXL23j5W6U3ftvGpySByT+9H45DU5exjHYkuvn5zUwyeW0WDNImRNgSLqMbuDARJVwUMOSNLQmNVHpWc= X-Received: by 2002:ac2:4255:: with SMTP id m21mr2204811lfl.383.1616620822398; Wed, 24 Mar 2021 14:20:22 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::136; envelope-from=lg.zevlg@gmail.com; helo=mail-lf1-x136.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:266985 Archived-At: --000000000000db0b1605be4edd8f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =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, resultin= g > 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 --=20 lg --000000000000db0b1605be4edd8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
=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.=C2=A0 Internally Emacs has decent suppo= rt for
> HiDPI displays.=C2=A0 However elisp code, that generates non-svg image= s don't
> have any idea that logical pixel may differ from physical one, resulti= ng 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.=C2=A0 This results in poor PNG quality since the physical pix= el is x4 times larger.=C2=A0 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

--
lg
--000000000000db0b1605be4edd8f--