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

[masm11]

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

[gkowzan]

Thanks for interest. I checked with display-pixel-width redefined as above and the result is bigger but not crisper (see here). Sorry for that, I assumed it's going to work fine with proper number of pixels. I also checked and it's the same on Xorg (Gnome Xorg with 200% scaling), so it's purely a Gdk problem. I'll investigate further, make a workaround and report back if there's anything on pgtk side that needs to be done.

[tsdh]

For reference, this is the AUCTeX bug report: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45596

[masm11]

Thank you for the file and the instruction.

I understand what you are saying.
I didn't understand because I tested on image-mode only.

[gkowzan]

I disagree, this is clearly a bug in pgtk affecting all Emacs functionality related to displaying bitmaps on scaled displays. Why not adjust the dimensions of the pixel buffer on which the bitmap is rendered by GDK_SCALE factor? Why would auctex or any other package set fake scaling factor when all it wants to do is to display a bitmap at natural scale? I don't need to do anything special to make Emacs render sharp fonts or other elements of the interface so why this exception for bitmaps? If a scaling factor needs to be included in every external Emacs code rendering images, then why not just do it in pgtk code? The burden of dealing with this shouldn't be imposed on third-party developers or users. I have identified and shown in this thread several packages affected by this:

1. preview-latex was discussed extensively. The same applies to org-mode latex preview or org-mode displaying any image in the document, or any other mode displaying images.
2. image.el. This is easy to check. Open in Emacs any jpg/png image, execute (image-transform-set-scale 1.0) so that Emacs does not scale the image to fit the window. Open the same image in imv (or compare with how it is displayed in your browser), execute :z actual. The size of displayed images will be different, with imv scaling the image correctly. Take this image for instance:
   
   This is what you'll get:
   
3. pdf-view, go back a few messages in this thread. It is clear that pdf-view prepares a bitmap and then pgtk stretches it over too many pixels. The problem is not on the side of the code generating the bitmap. There is no way for the user to correct that, so a patch would be required for pdf-view to work around that.

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

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

[masm11]

Gdk returns only scaled sizes.
I have no idea about how to get the unscaled ones.

If you re-define the functions as follows, do you get non-blurred image?

(defun display-pixel-width ()
  3840
)
(defun display-pixel-height ()
  2160
)

If so, I'll google once again.

[fejfighter]

0001-Return-native-pixels-on-scaled-screens.patch.txt

Try this patch, it uses GDK monitor which requires gdk 3.22 but I'm hoping that is not an issue for "new" emacs

it pulls the geometry and the scale factor to return to native pixels rather than application pixels in the gtk doco

ideally there should be a way to provide dpi instead, but that would require all terminals to get ported

(edit: debian 10 and redhat 7 both have gtk 3.22 should be ok)

[masm11]

@fejfighter

I seem not to have primary monitor...
(gdk_display_get_primary_monitor returns NULL.)

By the way, the comment of x-display-pixel-width says:

On \"multi-monitor\" setups this refers to the pixel width for all
physical monitors associated with TERMINAL.  To get information for
each physical monitor, use `display-monitor-attributes-list'.

This function should return the size of the screen, which contains all the monitors.
And it seems to be equal to the value of gdk_screen_get_width.

[fejfighter]

@masm11, right, it might be gnome doing it for me, which would explain why you were using gdk_display_get_monitor_at_point

I was mostly concerned about the deprecation notice in the GTK documentation for the use of gdk_screen_get_width
it might another case of emacs wanting to be an Xtoolkit and needing to know everything, but the information needed can be offered in a better way

@gkowzan it could be a scaling clash, could you set it back to no scaling, then take the screenshot?

[gkowzan]

@fejfighter What I found is that faking high DPI by redefining display-pixel-width gives me the same png file as the one I get when I set display output scaling to 1. preview-latex calls ghostscript with exactly the same arguments. Running Emacs without regenerating previews and changing sway to no scaling (output DP-1 mode 3840x2160 scale 1 position 0,0) gives me crisp previews (see this). After changing to scale 2 and reloading sway, Emacs renders the same png file like this.

Edit: preview-latex sets an image overlay to display the png. In the case above the display overlay is set to (image :file "/home/grz/auctex-debug/test.prv/tmpjesxF7/pr1-1.png" :type png :ascent 98), so it simply displays the image. If I change the overlay by hand to (image :file "/home/grz/auctex-debug/test.prv/tmpjesxF7/pr1-1.png" :type png :ascent 98 :scale 0.5), then the displayed image is sharp (see this).

[fejfighter]

I have had a look at this tonight, but have not had huge luck.

I think the way we have been handling dpi and scaling isn;t quite right
a few settings are set on start up and don't react to scale changes. (this will affect how it is rendered sometimes)

aside from that, something is not providing correct information for auctex, so things are blurry, I'm sure we can make the output better

[gkowzan]

Regarding providing information to preview-latex, it needs display-pixel-width to return the physical number of pixels and then it will generate the images as it should. The patch you provided should fix that, so there's nothing more to be done there.

A separate issue is how emacs-pgtk displays images on hidpi screens. preview-latex uses standard built-in image overlays, so if that gets fixed in emacs-pgtk, then preview-latex will work correctly. I think the scaling hack from my previous message shows that emacs-pgtk doesn't take into account dpi/scaling correctly. Unfortunately, I have zero expertise in Gtk and Emacs internals, so I can't help there.

[fejfighter]

Ahh right. I think I was stumbling around that area before (local) New Years hit and I called it a night. It’s likely something in gtkutil or an value in the frame structure I’ll have a look at it tomorrow

…

On Fri, 1 Jan 2021 at 00:17, gkowzan ***@***.***> wrote: Regarding providing information to preview-latex, it needs display-pixel-width to return the physical number of pixels and then it will generate the images as it should. The patch you provided should fix that, so there's nothing more to be done there. A separate issue is how emacs-pgtk displays images on hidpi screens. preview-latex uses standard built-in image overlays, so if that gets fixed in emacs-pgtk, then preview-latex will work correctly. I think the scaling hack from my previous message shows that emacs-pgtk doesn't take into account dpi/scaling correctly. Unfortunately, I have zero expertise in Gtk and Emacs internals, so I can't help there. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#90 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAE4EALDXOOGLH7WHDNSIBTSXR2VNANCNFSM4VNEXDWA> .

[masm11]

In multi-monitor environment, for example:

primary monitor:
  scale factor:   2
  absolute width: 3840
  logical width:  1920
  physical width: 290mm
secondary monitor:
  scale factor:   1
  absolute width: 1360
  logical width:  1360
  physical width: 710mm

display-pixel-width = 3280(current), 6560(with @fejfighter's fix)
display-mm-width = 290

I think returning logical width * scale factor does not work in multi-monitor environment.

@gkowzan
Can you use per-monitor information instead, i.e. display-monitor-attributes-list, if I can add scale-factor value in its return value?
(There will be scale-factor value only if pgtk-build)

[masm11]

Sorry, I mistook.

primary monitor:
  scale factor:   2
  absolute width: 3840
  logical width:  1920
  physical width: 290mm
secondary monitor:
  scale factor:   1
  absolute width: 1360
  logical width:  1360
  physical width: 710mm

display-pixel-width = 3280(current), 3840(with @fejfighter's fix)
display-mm-width = 290

When on the secondary monitor, dpi should be 1360px/710mm.
3840px/290mm is too high.

[gkowzan]

There is a bunch of issues here:

1. display-pixel-width is defined in docs to return total physical pixel width of "screen", so that's what it should return. Same applies to display-mm-width and height functions.
2. preview-latex using display-pixel-width and display-mm-width to determine DPI is wrong in my opinion, because it averages out DPI if you have mixed-DPI multi-monitor setup. In my case, with two monitors stacked vertically I get different horizontal and vertical DPI values, which results in funny-looking previews. It should probably use display-monitor-attributes-list to find out on which monitor the active frame is displayed and use that monitor's DPI.
3. The above doesn't actually matter under vanilla Emacs, because it looks like display-mm-width is adjusted so that DPI is always equal to 96, even if that's not true. This is probably why this method of calculating DPI actually works for vanilla Emacs. See below the results of calling the display functions under different Emacsen for my setup (the second element of preview-get-geometry is x, y DPI values):
4. I'm not a core Emacs/Auctex developer, so if pgtk is to be merged with main Emacs distribution, it might make sense at this point to raise these issues on Emacs mailing list.

vanilla emacs

;; display-pixel-width: 3840
;; display-mm-width: 1016
;; display-pixel-height: 3240
;; display-mm-height: 857
;; preview-get-geometry: (2.0 (96.0 . 96.02800466744458) [nil nil nil nil])

pgtk, Gnome Xorg, global scale 2 (no patches)

;; display-pixel-width: 1920
;; display-mm-width: 600
;; display-pixel-height: 1620
;; display-mm-height: 340
;; preview-get-geometry: (1.4 (81.28 . 121.02352941176471) [(61680 61680 61680) (14392 14906 16962) nil nil])

pgtk, swaywm, scale 2 and scale 1.5 (no patches)

;; display-pixel-width: 1920
;; display-mm-width: 600
;; display-pixel-height: 1800
;; display-mm-height: 340
;; preview-get-geometry: (1.4 (81.28 . 134.47058823529412) [(61680 61680 61680) (14392 14906 16962) nil nil])

For reference, my monitor setup is two screens stacked vertically:

Output DP-1 'Goldstar Company Ltd LG Ultra HD 0x0000996C'
  Current mode: 3840x2160 @ 59.997002 Hz
  Position: 0,0
  Scale factor: 2.000000

Output eDP-1 'Chimei Innolux Corporation 0x14D3 0x00000000' (focused)
  Current mode: 1920x1080 @ 60.007999 Hz
  Position: 0,1080
  Scale factor: 1.500000

[gkowzan]

@masm11 Regarding point 2, I can prepare a patch and submit it upstream.

Edit: I sent a bug report to auctex with the following redefinition of preview-get-geometry. This will provide correct DPI values to the rest of preview-latex pipeline, with both vanilla and pure GTK Emacs, as long as display-monitor-attributes-list (and related functions) returns the physical pixel dimensions of the monitors. The relevant change is encapsulated in the new function preview-get-dpi.

(defun preview-get-dpi ()
  (let* ((monitor-attrs (frame-monitor-attributes))
         (mm-dims (cdr (assoc 'mm-size monitor-attrs)))
         (mm-width (nth 0 mm-dims))
         (mm-height (nth 1 mm-dims))
         (pixel-dims (cdddr (assoc 'geometry monitor-attrs)))
         (pixel-width (nth 0 pixel-dims))
         (pixel-height (nth 1 pixel-dims)))
    (cons (/ (* 25.4 pixel-width) mm-width)
          (/ (* 25.4 pixel-height) mm-height))))

(defun preview-get-geometry ()
  "Transfer display geometry parameters from current display.
Returns list of scale, resolution and colors.  Calculation
is done in current buffer."
  (condition-case err
      (let* ((geometry
	      (list (preview-hook-enquiry preview-scale-function)
		    (preview-get-dpi)
		    (preview-get-colors)))
	     (preview-min-spec
	      (* (cdr (nth 1 geometry))
		 (/
		  (preview-inherited-face-attribute
		   'preview-reference-face :height 'default)
		  720.0))))
	(setq preview-icon (preview-make-image 'preview-icon-specs)
	      preview-error-icon (preview-make-image
				  'preview-error-icon-specs)
	      preview-nonready-icon (preview-make-image
				     'preview-nonready-icon-specs))
	geometry)
    (error (error "Display geometry unavailable: %s"
		  (error-message-string err)))))

[masm11]

I posted the question to the ML:
https://lists.gnu.org/archive/html/emacs-devel/2021-01/msg00038.html

[masm11]

I fixed these in feature/pgtk on savannah. Please try it.

• display-pixel-width/height returns physical pixel width/height.
• frame-monitor-attributes returns physical pixel position/width/height.
• display-mm-width/height consider multi-monitor.

[gkowzan]

I checked with the feature/pgtk branch. For my external monitor frame-monitor-attributes returns

((name . "LG Ultra HD") (geometry 0 0 3840 2160) (workarea 0 0 3840 2160) (mm-size 600 340) (frames #<frame rescale-overlays.el – Doom Emacs 0xfd9130>) (source . "Gdk"))

which is correct. For my internal display, it returns:

((name . "0x14D3") (geometry 0 2160 2560 1440) (workarea 0 2160 2560 1440) (mm-size 310 170) (frames #<frame rescale-overlays.el – Doom Emacs 0xfd9130>) (source . "Gdk"))

which is 1.5 times too large (should be 1920 by 1080 pixels). Before the fix it was:

((name . "LG Ultra HD") (geometry 0 0 1920 1080) (workarea 0 0 1920 1080) (mm-size 600 340) (frames #<frame rescale-overlays.el – Doom Emacs 0x2b8fd30>) (source . "Gdk"))
((name . "0x14D3") (geometry 0 1080 1280 720) (workarea 0 1080 1280 720) (mm-size 310 170) (frames #<frame rescale-overlays.el – Doom Emacs 0x2b8fd30>) (source . "Gdk"))

[masm11]

Yes.

I can't physical pixel size directly from Gdk, so I calculate it from logical pixel size and scale factor.
Because Gdk's scale factor is integer, I can't calculate it correctly if you specify fractional scale factor.

[masm11]

I'll create a function to set scale factor per monitor manually.
If it is set, it will be used instead of one from gdk.
If not set, scale factor from gdk will be used.

[masm11]

I created the function.

I pushed it to feature/pgtk of https://github.com/masm11/emacs before I push to savannah.

In your case, evaluate as follows to manually set scale factor.

(pgtk-set-monitor-scale-factor "0x14D3" 1.5)

And try preview.
You need to use display-monitor-attributes-list instead of display-pixel/mm-width/height.

If OK, then I'll push this branch to savannah.

[gkowzan]

@masm11
Thanks, the resolution and width values match physical values now. As far as I could tell, Emacs master ("impure" Gtk) also calls Gdk functions to populate display-monitor-attributes-list and it returns correct resolution under Xorg. Is it because of Wayland that the factor needs to be set manually with pgtk-set-monitor-scale-factor?

The previews are still blurry without the overlay scaling hack, but I suppose @fejfighter is working on that.

[masm11]

How do you configure scale factor to 1.5 on Xorg?

[gkowzan]

It's done on the level of UI framework. Under Gnome, I change font scale to 1.5 or change global scale (GDK_SCALE) to 2. Under KDE I set global scale to 1.5 and it adjusts the font sizes and widget sizes. Xorg/Xrandr settings are not changed.

Edit: Okay, sorry for bothering. It's clearly Wayland output scaling mucking things. Your most recent patched pgtk gives corrects values under Xorg without setting the scale manually:

;;; window-system: pgtk (xorg, patched)
;; display-pixel-width: 3840
;; display-mm-width: 600
;; implied DPI (height): 162.560000
;; display-pixel-height: 3240
;; display-mm-height: 513
;; implied DPI (width): 160.421053
;; display-monitor-attributes-list: (((name . "DP-1") (geometry 0 0 3840 2160) (workarea 0 64 3840 2096) (mm-size 600 340) (frames #<frame rescale-overlays.el – Doom Emacs 0x2b5b780>) (source . "Gdk")) ((name . "eDP-1") (geometry 0 2160 1920 1080) (workarea 0 2224 1920 1016) (mm-size 309 173) (frames) (source . "Gdk")))

;; "DP-1"
;; X-dpi: 162.560000
;; Y-dpi: 161.364706
;; "eDP-1"
;; X-dpi: 157.825243
;; Y-dpi: 158.566474

[masm11]

I change font scale to 1.5

It is just a font scaling, not monitor scale factor.
So monitor scale factor is 1, and physical and logical are equal.

change global scale (GDK_SCALE) to 2.

In this case, scale factor is integer. In the case of integer, physical pixel width can be calculated from gdk's values.

So physical pixel widths are correct in those cases on GNOME Xorg.

Under KDE I set global scale to 1.5 and it adjusts the font sizes and widget sizes.

I don't know much about KDE. But, maybe Gtk/Gdk doesn't consider KDE's global scale.
I'll confirm the case later.

Okay, sorry for bothering. It's clearly Wayland output scaling mucking things. Your most recent patched pgtk gives corrects values under Xorg without setting the scale manually

Thanks for the confirmation.
I'll push the branch to savannah for now.

[masm11]

Emacs treats images as pixel data.

Vanilla Emacs treats sizes as physical pixel size, so no problem.

Pgtk Emacs treats sizes as logical pixel size. When scale > 1, cr_create_surface_from_pix_containers creates small sized pixel data, and Gdk expands it when drawing. And blurry image is drawn.

Maybe that is the root cause...

[fejfighter]

@masm11 I think that is the case, I'm not sure how we can coerce GTK to not scale the image

I got in a bit of a loop in the GTK doco trying to determine how to identify a scale change event, it's seemingly a configure event, where nothing changes, but it happens enough that a redraw each time is expensive.

@gkowzan there is an auctex commit that uses native pixels and might help, I ran out of time to build and test that change but it might work, longer term I wonder if the equations could be rendered using SVG or similar, that would make everything work cleaner, but would need some back end work

[gkowzan]

@fejfighter Yes, @tsdh commited a modified version of my preview-get-dpi and preview-get-geometry and it will be included in the next auctex release. Blurriness is still a problem either way. Did you mean this specific commit? I checked that images are too large/blurry even if I just view them with image-mode, i.e. I open one of my screenshots from this issue and it's too big blurry, but when I scale it with image-transform-set-scale by 0.5, then it looks as it should.

Org-mode LaTeX previews can display SVGs, so it might make sense to port it to auctex. (It's a shame org-mode duplicated latex preview machinery instead of leveraging it like texfrag-mode does.)

[masm11]

@gkowzan

I open one of my screenshots from this issue and it's too big blurry,

Do you mean any image files are incorrect size when monitor scale is 1.5?

[gkowzan]

They are incorrect when scale is either 2.0 or 1.5. See this screenshot (https://imgur.com/a/cFRjwBg), left buffer is the screenshot of the right buffer. Now the same after calling (image-transform-set-scale 0.5): https://imgur.com/f8qt1Pp

[masm11]

I confirmed. Image should be shrink or enlarge to fit the emacs window, but it doesn't on sway.
No problem on wayfire.

By the way, does your pgtk emacs support imagemagick? If so, try disabling it. Image blurriness may improve somewhat.

[gkowzan]

(image-type-available-p 'imagemagick) gives nil so no ImageMagick. I get improper scaling on Gnome (Wayland and Xorg), sway and wayfire 0.5.

[masm11]

The same even if emacs -Q?
Also, could you give me the config of wayfire?

[gkowzan]

Yes, checked emacs -Q with a build of feature/pgtk branch from savannah under wayfire 0.5. Here's the config.

[masm11]

Thanks, but incorrect size does not reproduce. This is on wayfire 0.5.0.

Could you tell me values of system-configuration-options and system-configuration-features?
Here is mine:

system-configuration-options
"--with-pgtk --without-x --with-cairo --with-modules --with-gif=yes --with-tiff=yes --without-imagemagick --with-xwidgets --with-gnutls=no --without-pop --enable-gcc-warnings=warn-only --enable-checking=yes,glyphs --enable-check-lisp-object-type=yes 'CFLAGS=-O0 -g3 -no-pie'"
system-configuration-features
"JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY ACL LIBXML2 FREETYPE HARFBUZZ LIBOTF ZLIB TOOLKIT_SCROLL_BARS GTK3 PGTK XIM MODULES THREADS XWIDGETS LIBSYSTEMD JSON PDUMPER LCMS2"

[gkowzan]

My values are the ones from deathwish/emacs-ptk-nativecomp copr:

system-configuration-options
"--build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png --with-rsvg --with-tiff --with-xft --with-xpm --with-gpm=no --with-xwidgets --with-modules --with-harfbuzz --with-cairo --with-json --with-pgtk --with-nativecomp --enable-link-time-optimization build_alias=x86_64-redhat-linux-gnu host_alias=x86_64-redhat-linux-gnu CC=gcc 'CFLAGS=-DMAIL_USE_LOCKF -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' LDFLAGS=-Wl,-z,relro PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig"
system-configuration-features
"JPEG TIFF GIF PNG RSVG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ LIBOTF ZLIB TOOLKIT_SCROLL_BARS GTK3 PGTK XIM MODULES NATIVE_COMP THREADS XWIDGETS LIBSYSTEMD JSON PDUMPER LCMS2"

but I don't think it matters because I compiled feature/pgk with your configuration options, checked under wayfire with emacs -Q and the result was the same. I did a sanity check by opening the same image with imv and setting :zoom actual, and the scaling was correct. (Eye of Gnome, on the other hand, also scales images incorrectly.)

[masm11]

Thanks for the values.

give up for a while...

[masm11]

In the case of imagemagick there was a cause of blurriness, which has been fixed.
You told me that your pgtk emacs doesn't support imagemagick, so it is not the case.

Incorrect image size is not reproducible and not fixed.

[masm11]

I tried fedora 32 live image and copr deathwish/emacs-pgtk-nativecomp, and open a png file in it.
GNOME display scale setting is 200%.

No problem.

[gkowzan]

@masm11 Thank you for checking! Could you also check with an image which is smaller than your Emacs window? If the image is so big that Emacs rescales it to fit the frame, then it's less likely to be blurry. I also found that opening pdfs with pdf-view.el always makes them blurry. I will check on my side what could possibly cause the issue when I have the time.

[masm11]

When I open a small image in emacs, it scales according to the scale setting and it is blurry.
Is that your issue?

[gkowzan]

Yes, that is precisely the issue. At natural scaling, zoom set to 1.0, images are displayed on more pixels than they should be and that makes the images blurry in latex previews. This is also the cause of blurry display of PDFs, see the attached image and compare the text rendered by sway/waybar or Emacs on modeline and the PDF text.

[masm11]

If a image is 100x100 and monitor scale setting is 200%,
it occupy 200x200, and it is blurry.

If a image generated by latex preview is blurry, then
latex preview should generate larger image.
I understand this point should be fixed by display-monitor-attributes-list fixes and auctex's display-monitor-attributes-list usage.

Am I wrong?

[gkowzan]

If a image generated by latex preview is blurry, then latex preview should generate larger image. I understand this point should be fixed by display-monitor-attributes-list fixes and auctex's display-monitor-attributes-list usage.

Currently it doesn't work that way. If preview-latex renders a large image, then pgtk will upscale it anyway and it will be blurry. My preview-latex fix causes auctex to generate larger images but pgtk still needs to stop upscaling the images. See side-by-side comparison of Evince rendering a PDF and Emacs pgtk rendering a PDF. What happens is that pdf-mode provides an image which should be rendered on a smaller region and pgtk upscales it, so no matter the image it's always displayed blurry.

[masm11]

Can you give me a sample tex file to reproduce it? I have not used tex recently.

[gkowzan]

Sure, this is an example latex file:

\documentclass{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{amsopn}

\begin{document}
This is the Schr\"odinger equation:
\begin{equation}
  i\hbar\frac{\partial\Psi}{\partial t} = \hat{H}\Psi.
\end{equation}
\end{document}

When using auctex and preview-latex, you can use C-c C-p C-d to generate previews in the document. Then if your point is at the preview overlay, you can execute the following snippet with M-: to downscale the preview:

(let* ((ov (first (overlays-at (point))))
       (display-plist (cdr (overlay-get ov 'display)))
       (new-display-plist (plist-put display-plist :scale 0.5)))
  (overlay-put ov 'display `(image . ,new-display-plist)))

[masm11]

Generating the large image is done in auctex, so shrinking it should be also done in auctex.
i.e. auctex should include :scale 0.5 in overlay properties.

To calculate the correct :scale value, I added scale-factor in the return value of
display-monitor-attributes-list.

[masm11]

I wrote the code to display all the images half size for test, and confirmed latex preview's image is correct, but
the image in emacs splash screen is too small. So I thought I couldn't apply for all the cases.

For the case of image.el, when (image-transform-set-scale 1.0), the image should be
displayed in double size as text displayed in double size, because the monitor scale is 200%.
For the given Emacs logo image, pgtk emacs displays it in the same size as Firefox does.

[masm11]

(This comment is translated by google translate)

Just as text is doubled in size, images should be doubled in size.
In the case of (image-transform-set-scale 1.0) in image.el, it is twice the size.

The text has a size in the font data, and the font size can be determined when actually drawing.
UI bitmaps are also available in various sizes, allowing you to choose the size you want.
But when displaying an image, there is only one.
Therefore, if you try to display it at twice the size, you need to enlarge the image, which is blurry.

Most elisps that work with images can't avoid it.
But for some elisp it can be avoided.
An elisp that produces an image, like the auctex preview, can generate a large size and shrink it as it is displayed.

[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]

@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: vedang/pdf-tools#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: vedang/pdf-tools#13

Thank you! I'll do that!

[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!