all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: Po Lu <luangruo@yahoo.com>, emacs-devel@gnu.org
Subject: Re: Display scaling?
Date: Mon, 31 Jan 2022 17:13:38 +0200	[thread overview]
Message-ID: <ac715e99-a05a-ef9d-98c2-826b5f24a3ad@yandex.ru> (raw)
In-Reply-To: <877danm1ds.fsf@yahoo.com>

On 26.01.2022 08:55, Po Lu wrote:
> It would be opt-in behaviour, of course.

I rather think it makes sense to make it opt-out: we should strive for 
consistent looks of fringes between ports, HiDPI included.

Or to make it opt-in for all ports (NS and PGTK included), and then 
decide on the default based on the collective user feedback.

Regarding fringes, I was going to suggest providing different scaled 
versions of bitmaps (which was already mentioned in this thread) -- 
having even two versions, 1x and 2x, should cover a lot of users -- but 
it seems like a half-measure that requires extra work from the bitmap 
authors.

Before going to vector formats, could we try tweaking the scaling 
algorithm first? E.g. when the scaling is 2x (which seems popular 
enough), the bitmap could be "zoomed up" without any fuzziness.

It could also be made customizable.

Downscaling seems less lossier than upscaling as well, so if the scaling 
factor is 1.5x (for example), the bitmap can be "zoomed up" to 2x first, 
and then downscaled to 1.5x using bicubic interpolation or etc. IIUC 
Gnome Shell uses this approach to implement fractional scaling for its 
UI elements.

Or if we were trying to pick an algorithm which can be found in some 
library, perhaps choose from one of these? 
https://en.wikipedia.org/wiki/Pixel-art_scaling_algorithms

Starting with "nearest neighbor". I'm curious how it would look on the 
built-in bitmaps.



  parent reply	other threads:[~2022-01-31 15:13 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <877danm1ds.fsf.ref@yahoo.com>
2022-01-26  6:55 ` Display scaling? Po Lu
2022-01-26  8:38   ` Eric S Fraga
2022-01-26 12:57   ` Eli Zaretskii
2022-01-26 13:17     ` Po Lu
2022-01-26 13:33       ` Eli Zaretskii
2022-01-26 13:36         ` Po Lu
2022-01-26 14:50           ` Eli Zaretskii
2022-01-27  0:57             ` Po Lu
2022-01-27  6:29               ` Eli Zaretskii
2022-01-27  6:42                 ` Po Lu
2022-01-27 10:51                   ` Po Lu
2022-01-27 11:02                     ` Eli Zaretskii
2022-01-27 11:08                       ` Po Lu
2022-01-27 11:22                         ` Eli Zaretskii
2022-01-27 11:35                           ` Po Lu
2022-01-26 13:16   ` Lars Ingebrigtsen
2022-01-26 13:37     ` Po Lu
2022-01-31 15:13   ` Dmitry Gutov [this message]
2022-02-01  1:05     ` Po Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ac715e99-a05a-ef9d-98c2-826b5f24a3ad@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=emacs-devel@gnu.org \
    --cc=luangruo@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.