Display scaling?

Display scaling?

[Po Lu]

Right now, the PGTK and NS ports apply a so-called "device scale", which
means that all drawing operations have an integral scale applied when
the user asks for it (for example, when he has a HiDPI monitor.)

The X and (presumably) W32 ports, however, only scale text on such
monitors, which means things that aren't text (such as the fringes and
boxes) are often displayed too tiny to be legible.

I think it would be nice to have such scaling on the other ports as
well.  We could probably apply the frame's display scale to the width of
its boxes when a face is being realized, and apply the scale to the the
fringe and its bitmaps as well.

It would be opt-in behaviour, of course.

WDYT?

Re: Display scaling?

[Eric S Fraga]

On Wednesday, 26 Jan 2022 at 14:55, Po Lu wrote:
> and apply the scale to the the fringe and its bitmaps as well.

I would love to see this.  The fringe markers, at least for me, are
close to indecipherable on large monitors (given my eyesight).

Thank you,
eric

-- 
Eric S Fraga with org 9.5.2 in Emacs 29.0.50 on Debian 11.2

Re: Display scaling?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Date: Wed, 26 Jan 2022 14:55:59 +0800
> 
> The X and (presumably) W32 ports, however, only scale text on such
> monitors, which means things that aren't text (such as the fringes and
> boxes) are often displayed too tiny to be legible.
> 
> I think it would be nice to have such scaling on the other ports as
> well.  We could probably apply the frame's display scale to the width of
> its boxes when a face is being realized, and apply the scale to the the
> fringe and its bitmaps as well.
> 
> It would be opt-in behaviour, of course.

What is your plan to scaling the fringe bitmaps?

Re: Display scaling?

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> The X and (presumably) W32 ports, however, only scale text on such
> monitors, which means things that aren't text (such as the fringes and
> boxes) are often displayed too tiny to be legible.

create-image does scale images on X, but find-image (used for the
fringes, I think?) doesn't.  See bug#47039 -- find-image should be
changed to use the normal create-image functions, and then it'd resolve
itself.  Probably.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Display scaling?

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> What is your plan to scaling the fringe bitmaps?

We should scale the bitmaps by the same factor by which the fringe width
is scaled, which is what happens on the NS and PGTK ports when a device
scale is applied.  It will require some code on the window system
backend side, but not too much.

Thanks.

Re: Display scaling?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 26 Jan 2022 21:17:30 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What is your plan to scaling the fringe bitmaps?
> 
> We should scale the bitmaps by the same factor by which the fringe width
> is scaled, which is what happens on the NS and PGTK ports when a device
> scale is applied.  It will require some code on the window system
> backend side, but not too much.

But bitmap images don't scale well, they look ugly (pixelated) after
scaling.

Re: Display scaling?

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> But bitmap images don't scale well, they look ugly (pixelated) after
> scaling.

We could introduce higher-resolution (and perhaps even colourful) fringe
bitmaps after the scaling feature is finished, but I think the priority
right now is to make the fringes at least comfortably visible on such
monitors.

Thanks.

Re: Display scaling?

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> create-image does scale images on X, but find-image (used for the
> fringes, I think?) doesn't.  See bug#47039 -- find-image should be
> changed to use the normal create-image functions, and then it'd resolve
> itself.  Probably.

The fringes are completely separate from our regular image support.  See
`define-fringe-bitmap' and also the standard bitmaps in fringe.c.

Thanks.

Re: Display scaling?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 26 Jan 2022 21:36:35 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > But bitmap images don't scale well, they look ugly (pixelated) after
> > scaling.
> 
> We could introduce higher-resolution (and perhaps even colourful) fringe
> bitmaps after the scaling feature is finished, but I think the priority
> right now is to make the fringes at least comfortably visible on such
> monitors.

From past discussions, the initial solution you propose will be
considered as bug by users.

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.

Re: Display scaling?

[Po Lu]

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?  AFAIU, the scaling on
the NS and PGTK ports is generally considered superior to the other
ports, and they simply scale the bitmaps up.

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

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.

Thanks.

Re: Display scaling?

[Eli Zaretskii]

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

Re: Display scaling?

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Sorry, I don't have the references handy.  You'll need to search the
> archives for HiDpi+fringe+bitmap, perhaps.

Thanks.

> You mean, if you scale up enough, you actually see the pixels as small
> squares?

Yes, indeed.  People say that looks better than a tiny unreadable
fringe, which is why I think such a temporary solution would be an
improvement until we can find a good solution for completely supporting
multiple 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.
>
> That's exactly the issue that may need to be resolved, yes.  If indeed
> we want to support a large number of scales.

Thanks, I'll look into that as well; maybe it would be acceptable to use
SVG to render the fringes after all, since judging by recent bug reports
most users already have librsvg installed.

Re: Display scaling?

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> Yes, indeed.  People say that looks better than a tiny unreadable
> fringe, which is why I think such a temporary solution would be an
> improvement until we can find a good solution for completely supporting
> multiple scales.

If nobody has any objections, I'll start implementing the scaling of
fringes this way, and also the scaling of boxes and tool bar icon
margins.

Thanks.

Re: Display scaling?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 27 Jan 2022 18:51:21 +0800
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> > Yes, indeed.  People say that looks better than a tiny unreadable
> > fringe, which is why I think such a temporary solution would be an
> > improvement until we can find a good solution for completely supporting
> > multiple scales.
> 
> If nobody has any objections, I'll start implementing the scaling of
> fringes this way, and also the scaling of boxes and tool bar icon
> margins.

Given the past discussions, I'd prefer to have this on a branch, so
that people could try it and return feedback, before we decide whether
to land this on master.

Thanks.

Re: Display scaling?

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Given the past discussions, I'd prefer to have this on a branch, so
> that people could try it and return feedback, before we decide whether
> to land this on master.

I'm fine with that too, but I intend to have this behaviour completely
opt-in anyway, so perhaps that isn't entirely necessary.

BTW, is it okay for me to create a feature branch on master, or does
someone else have to do it?

Thanks.

Re: Display scaling?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 27 Jan 2022 19:08:03 +0800
> 
> I'm fine with that too, but I intend to have this behaviour completely
> opt-in anyway, so perhaps that isn't entirely necessary.

I'd prefer not to have on master code that we are not sure will be
kept.

> BTW, is it okay for me to create a feature branch on master, or does
> someone else have to do it?

You can do it yourself (and the branch is not "on master", it is just
another branch, a sibling of the master branch).

Re: Display scaling?

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I'd prefer not to have on master code that we are not sure will be
> kept.

I see, thanks.

> You can do it yourself (and the branch is not "on master", it is just
> another branch, a sibling of the master branch).

Sorry, I meant to say "on savannah".

Re: Display scaling?

[Dmitry Gutov]

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.

Re: Display scaling?

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

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

I tend to agree.

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

That interferes with GTK and NS's own device scaling, which this feature
is trying to replicate.

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

There wouldn't be any fuzziness on HiDPI displays, since it would look
identical to such a bitmap on a normal display.

> It could also be made customizable.

Indeed.

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

I'll give that a try some time.