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: Wed, 10 Feb 2021 21:01:35 -0500


> On Feb 10, 2021, at 6:55 PM, Alan Third <alan@idiocy.org> wrote:
> 
> On Wed, Feb 10, 2021 at 01:00:52PM -0500, Yuan Fu wrote:
>> I agrees that we should keep the logical size, i.e., keep the size
>> comparing against text. If we expose correct physical size, packages
>> that generate bitmaps for display can generate crisp bitmaps with
>> correct pixel size.
>> 
>> IIUC, a high-res image with :scale 0.5 should work across high and
>> low-res displays. So ideally any package that wants to generate
>> crisp bitmap can get the physical size and pixel-ratio from Emacs,
>> generate the image and set :scale to 1/pixel-ratio. And this image
>> works across different displays.
> 
> Yes, until the users drags the frame from a scale factor 1 screen to a
> scale factor 2 screen, then it's blurry again. But I really don't
> think there is a satisfactory solution to that.

I think that’s fine. If the user don’t want his image to be blurry, he should 
provide a high-enough-resolution image.

> 
>>> We'll probably have to do more fiddling with SVGs though, since they
>>> can define sizes in real-world units, like cm or inches, so the dpi
>>> has to match the physical pixels, and if we move to a different screen
>>> and regenerate the SVG the DPI will be different but the scale likely
>>> won't be recalculated and the image will change size.
>> 
>> To simplify things, maybe we can assume DPI is 96. I.e., assume 1
>> inch = 96 logical pixels = 96 * pixel-ratio physical pixels.
>> 
>> Obviously, if we can get DPI information from all terminals, then we
>> could use that information. But from your previous message it
>> doesn’t seem easy.
> 
> After messing about a bit today, I think the DPI thing is a red
> herring. If we calculate the logical size of the SVG, then just
> multiply it by the scale factor, then when drawing scale it down by
> the scale factor everything is the right size and we can forget about
> modifying the dpi.
> 
>> For SVGs I think we should automatically handle the pixel ratio and
>> dpi so the image is always crisp and lisp doesn’t need to do
>> anything (don’t need to add the :scale attribute or anything).
>> 
>> For bitmap images I think we display them in their physical size and
>> let lisp alter the size by the :scale attribute.
>> 
>> For :width and :height attributes, I think they should be in logical
>> pixels.Because the ratio of logical pixels and other text in a
>> buffer doesn’t change when you drag a frame across different
>> displays. So if the user set an image to have certain :width and
>> drag the frame to a different display, the image doesn’t change its
>> size comparing to everything else in the buffer.
> 
> Attached is a first go at this. I can't work out image.el and
> image-mode.el, so I'll either need a lot more time or someone more
> familiar with them can have a look.
> 
> The basic problem is that image-size returns physical pixels, and we
> want to calculate logical pixels. I tried a few things and failed
> miserably. I tried changing image-size to return logical pixels, but
> that just seemed to make everything worse, and I don't think it's a
> good idea to lie about the image size.

I’m not sure what do you want to achieve here. Are you trying to automatically 
size bitmap images when opening them, so that it is displayed 1:1 to physical 
pixels? If can do something like this:

(insert-image (create-image "~/d/Screen Shot 2021-02-09 at 10.11.56 AM.png"
                            nil nil :scale (/ 1 (frame-scale-factor))))

And the image inserted is displayed 1:1 to physical pixels. But :scale is not 
really meant for controlling pixel ratio. Maybe we should add a :pixel-ratio 
(or :scale-factor) attribute to control the default display size of a bitmap 
image?

> Anyway, SVGs will display nicely on macOS with the attached patch, and
> frame-scale-factor returns a useful value. I didn't write the code for
> GTK yet, but I guess it's probably not too hard.

Yes, SVGs worked well!

> 
> I guess we also want to change the ghostscript code to do the same
> thing as the SVG code too?

I think so.

Another question is what unit should :width and :height attributes use, but I 
guess we can discuss them later.

Yuan


reply via email to

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