Closed gkowzan closed 3 years ago
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.
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)
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.
@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
.
@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?
@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).
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
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.
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 notifications@github.com 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 https://github.com/masm11/emacs/issues/90#issuecomment-752956228, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAE4EALDXOOGLH7WHDNSIBTSXR2VNANCNFSM4VNEXDWA .
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)
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.
There is a bunch of issues here:
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.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.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):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
@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)))))
I posted the question to the ML: https://lists.gnu.org/archive/html/emacs-devel/2021-01/msg00038.html
I fixed these in feature/pgtk on savannah. Please try it.
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"))
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.
For reference, this is the AUCTeX bug report: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45596
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.
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.
@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.
How do you configure scale factor to 1.5 on Xorg?
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
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.
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...
@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
@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.)
@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?
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
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.
(image-type-available-p 'imagemagick)
gives nil
so no ImageMagick. I get improper scaling on Gnome (Wayland and Xorg), sway and wayfire 0.5.
The same even if emacs -Q
?
Also, could you give me the config of wayfire?
Yes, checked emacs -Q
with a build of feature/pgtk
branch from savannah under wayfire 0.5. Here's the config.
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"
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.)
Thanks for the values.
give up for a while...
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.
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.
@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.
When I open a small image in emacs, it scales according to the scale setting and it is blurry. Is that your issue?
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.
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?
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.
Can you give me a sample tex file to reproduce it? I have not used tex recently.
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)))
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.
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
.
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:
(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:
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.
(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.
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 topreview-get-geometry
function inauctex/preview.el
file, which uses results ofdisplay-pixel-width
anddisplay-mm-width
to calculate the DPI and set the resolution of generated previews (command line arguments for ghostscript/dvipng). For my casedisplay-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?