emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "Fix" sag scaling for hidpi


From: Yuan Fu
Subject: Re: "Fix" sag scaling for hidpi
Date: Sat, 13 Feb 2021 21:06:57 -0500


> On Feb 13, 2021, at 7:02 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
> On 14.02.2021 01:14, Alan Third wrote:
>> On Sun, Feb 14, 2021 at 12:50:26AM +0200, Dmitry Gutov wrote:
>>> I noticed the pgtk and the GTK3 builds render them in different size at 2x
>>> scaling. Basically, pgtk scales (and renders them kind of fuzzily) and GTK3
>>> does not. I wonder if their rendering could be standardized as well, and
>>> whether the same approach could be used to avoid fuzziness.
>> Really I think we should be providing hi-res, or vector, versions of
>> the fringe bitmaps for hi-dpi screens.
>> I'm not sure if we can just swap in SVG files for the fringe bitmaps
>> on systems that support them... Fringe bitmaps are special in some
>> way.
> 
> But couldn't we use a non-fuzzy algorithm to scale them, at least as a 
> fallback? If the bitmap is all 1s an 0s, scaling by 2x could just double the 
> lattice instead of doing the linear scaling.
> 
> Or there might be other scaling algorithms as well, if people feel that that 
> approach ends up looking too "blocky".
> 
> There are an infinite number of possible scaling factors, so providing a 
> high-res version for all of them is probably out, but some vector format 
> sounds like an interesting possibility. As long as it's feasible to generate 
> programmatically, because that's what I'm doing with a bunch of fringe 
> bitmaps in a certain popular minor mode.

You can definitely generate SVG’s with sag-mode. For example, to generate a 
downward arrow:

(let ((svg (svg-create 9 9)))
         (svg-polygon svg '((0 . 0) (9 . 0) (4.5 . 9)) :fill "black")
         (svg-image svg))

Yuan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]