Blurry preview-latex, display-pixel-width returns number of pixels after scaling

[gkowzan]

I'm using swaywm with high DPI scaling (output DP-1 mode 3840x2160 scale 2 position 0,0) and LaTeX previews are blurry (see image). I tracked down the problem to preview-get-geometry function in auctex/preview.el file, which uses results of display-pixel-width and display-mm-width to calculate the DPI and set the resolution of generated previews (command line arguments for ghostscript/dvipng). For my case display-pixel-width returns value of 1920 (3840/2), whereas running under X server it returns the actual number of pixels - 3840.

Does the pgtk fork provide any facility to retrieve the actual, unscaled number of pixels or DPI directly? What would be the preferred and clean way to fix this issue?

[gkowzan]

Well, I give up. I can't see a scenario where upscaling bitmaps and rendering their blurry versions by default is a useful and expected outcome.

[VitalyAnkh]

Any updates? I also suffer from this problem. Or, what should we do to resolve this problem?

[VitalyAnkh]

There is a discussion about this on emacs-devel mailing list: https://lists.gnu.org/archive/html/emacs-devel/2021-02/msg00241.html

[VitalyAnkh]

A better way: let Emacs use logical pixel other than physical pixel?

[masm11]

There are currently two threads about blurriness on hidpi: https://lists.gnu.org/archive/html/emacs-devel/2021-02/msg00241.html https://lists.gnu.org/archive/html/emacs-devel/2021-02/msg00233.html

I'm watching them.

A better way: let Emacs use logical pixel other than physical pixel?

pgtk emacs uses logical pixel.

[jeslie0]

Has there been any development or progress with this that anyone knows about?

[masm11]

I think I can do nothing. I'll close this issue with wontfix.

[jeslie0]

I have also found that this issue affects any program that emacs opens. For instance, opening zathura with auctex, or firefox from eshell causes the resulting windows to be blurry too. Maybe this can help someone in the future fix the issue.

Edit: This is an unrelated issue, which was solved by @akirakyle.

[masm11]

Thank you for the additional information. I'm closing this issue for now.

[akirakyle]

Something definitely has to be fixed here, but I guess the question is what and where. @masm11 Is the following an accurate summary of the discussions about this issue so far?

The current behavior with respect to always scaling bitmap/raster images according to a monitor's scale factor is correct and consistent with other apps so pgtk emacs shouldn't do something different like always displaying bitmap images at their native resolution (doing so would also mean bitmap ui elements would be incorrectly scaled).

For vector images like an svg or pdf, it seems pgtk emacs displays them at the correct size, however since they've been upscaled, they look blurry even though they can be rendered at the native resolution with a scaled size. I think @masm11 correctly identified that this probably isn't the job of pgtk, but of code in svg.el or doc-view or pdf-tools to render upscaled bitmaps from the underlying vector data. I might start looking for fixes for svg.el and pdf-tools if I have the time.

[akirakyle]

@jeslie0, that seems like a mostly unrelated issue since emacs has no control over how other apps render themselves. Most likely its some environment variables they're inheriting from emacs that is causing strange behavior. This could probably be checked easily, but I cannot reproduce your issue on my system (using sway).

[akirakyle]

@masm11 I think it would help to implement frame-scale-factor for pgtk, that way the improvements being made to pdf-tools to support HiDPI on ns will also work for pgtk: https://github.com/vedang/pdf-tools/pull/13

[jeslie0]

@akirakyle How bizarre - I think you are right. I deleted my emacs env file and let it regenerate. The program blurriness is gone now. Thanks!

Edit: It looks like it was missing GTK_BACKEND=wayland, for some reason.

[masm11]

@akirakyle

Is the following an accurate summary of the discussions about this issue so far?

Yes. But it is just my opinion.

I think it would help to implement frame-scale-factor for pgtk, that way the improvements being made to pdf-tools to support HiDPI on ns will also work for pgtk: https://github.com/vedang/pdf-tools/pull/13

Thank you! I'll do that!

[masm11]

I implemented frame-scale-factor. But pdf-tools needs a small work to support it.

[masm11]

There seemed to be no need to do "a small work". You need to use latest pdf-tools, and do:

(setq pdf-view-use-scaling t)

You'll get criper pdf images.

[VitalyAnkh]

I implemented frame-scale-factor. But pdf-tools needs a small work to support it.

Thanks! It works! You are my hero!

[jeslie0]

It looks to me like the latex-fragment are now rendering properly. Thank you so much for managing to fix it!