From: Eli Zaretskii <eliz@gnu.org>
To: Po Lu <luangruo@yahoo.com>
Cc: emacs-devel@gnu.org
Subject: Re: Display scaling?
Date: Thu, 27 Jan 2022 08:29:03 +0200 [thread overview]
Message-ID: <83ilu5g09c.fsf@gnu.org> (raw)
In-Reply-To: <87mtjiknbc.fsf@yahoo.com> (message from Po Lu on Thu, 27 Jan 2022 08:57:27 +0800)
> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 27 Jan 2022 08:57:27 +0800
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > From past discussions, the initial solution you propose will be
> > considered as bug by users.
>
> Could you point me to some of those discussions?
Sorry, I don't have the references handy. You'll need to search the
archives for HiDpi+fringe+bitmap, perhaps.
> AFAIU, the scaling on the NS and PGTK ports is generally considered
> superior to the other ports, and they simply scale the bitmaps up.
You mean, if you scale up enough, you actually see the pixels as small
squares?
> > In the past we discussed only 2 resolutions, in which case providing
> > another set of fringe bitmaps sounds plausible. But you seem to be
> > talking about supporting any arbitrary scale, not just the double one
> > of HiDpi displays, and that calls for a different implementation that
> > we should IMO think over up front.
>
> Some of those monitors already default to a 400% scale, so GNOME and NS
> already aren't constrained to double scales.
My point wasn't about the scale value itself, it was about the number
of scale values we want to support. If it is a small number of
discrete values, we could prepare bitmaps for each of the supported
values, but if the number is practically infinite, we cannot use such
a solution.
> How about using a vector graphics format for the "new" fringe bitmaps?
> We already have SVG support, but IMHO SVG is too heavy and isn't present
> on every system, so maybe a custom vector graphics format for fringe
> bitmaps would be in order.
That's exactly the issue that may need to be resolved, yes. If indeed
we want to support a large number of scales.
next prev parent reply other threads:[~2022-01-27 6:29 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 [this message]
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
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83ilu5g09c.fsf@gnu.org \
--to=eliz@gnu.org \
--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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).