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.
next prev 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.