masm11 / emacs

Mirror of GNU Emacs
http://www.gnu.org/software/emacs/
GNU General Public License v3.0
198 stars 14 forks source link

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

Closed gkowzan closed 3 years ago

gkowzan commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

VitalyAnkh commented 3 years ago

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

VitalyAnkh commented 3 years ago

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

masm11 commented 3 years ago

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 commented 3 years ago

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

masm11 commented 3 years ago

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

jeslie0 commented 3 years ago

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 commented 3 years ago

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

akirakyle commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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

masm11 commented 3 years ago

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 commented 3 years ago

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

Thanks! It works! You are my hero!

jeslie0 commented 3 years ago

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