Blurry preview-latex, display-pixel-width returns number of pixels after scaling #90
Comments
|
Gdk returns only scaled sizes. 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 |
|
I seem not to have primary monitor... By the way, the comment of This function should return the size of the screen, which contains all the monitors. |
|
@masm11, right, it might be gnome doing it for me, which would explain why you were using I was mostly concerned about the deprecation notice in the GTK documentation for the use of @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 Edit: preview-latex sets an image overlay to display the png. In the case above the |
|
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 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 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 ***@***.***> 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>
.
|
|
In multi-monitor environment, for example: I think returning @gkowzan |
|
Sorry, I mistook. When on the secondary monitor, dpi should be 1360px/710mm. |
|
There is a bunch of issues here:
vanilla emacs pgtk, Gnome Xorg, global scale 2 (no patches) pgtk, swaywm, scale 2 and scale 1.5 (no patches) For reference, my monitor setup is two screens stacked vertically: |
|
@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 |
|
I posted the question to the ML: |
|
I fixed these in feature/pgtk on savannah. Please try it.
|
|
I checked with the feature/pgtk branch. For my external monitor which is correct. For my internal display, it returns: which is 1.5 times too large (should be 1920 by 1080 pixels). Before the fix it was: |
|
Yes. I can't physical pixel size directly from Gdk, so I calculate it from logical pixel size and 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. |
|
I created the function. I pushed it to In your case, evaluate as follows to manually set scale factor. (pgtk-set-monitor-scale-factor "0x14D3" 1.5)And try preview. If OK, then I'll push this branch to savannah. |
|
@masm11 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: |
It is just a font scaling, not monitor scale factor.
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.
I don't know much about KDE. But, maybe Gtk/Gdk doesn't consider KDE's global scale.
Thanks for the confirmation. |
|
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, 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 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.) |
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 |
|
I confirmed. Image should be shrink or enlarge to fit the emacs window, but it doesn't on sway. By the way, does your pgtk emacs support imagemagick? If so, try disabling it. Image blurriness may improve somewhat. |
|
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%, If a image generated by latex preview is blurry, then Am I wrong? |
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 (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. |
|
Generating the large image is done in auctex, so shrinking it should be also done in auctex. To calculate the correct |
|
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:
|
|
I wrote the code to display all the images half size for test, and confirmed latex preview's image is correct, but For the case of image.el, when (image-transform-set-scale 1.0), the image should be |
|
(This comment is translated by google translate) Just as text is doubled in size, images should be doubled in size. The text has a size in the font data, and the font size can be determined when actually drawing. Most elisps that work with images can't avoid it. |
|
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. |
|
Any updates? I also suffer from this problem. |
|
There is a discussion about this on emacs-devel mailing list: |
|
A better way: let Emacs use logical pixel other than physical pixel? |
|
There are currently two threads about blurriness on hidpi: I'm watching them.
pgtk emacs uses logical pixel. |
|
Has there been any development or progress with this that anyone knows about? |
|
I think I can do nothing. |
|
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. |
|
Thank you for the additional information. |
|
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. |
|
@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 I think it would help to implement |
|
@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. |
Yes. But it is just my opinion.
Thank you! I'll do that! |
|
I implemented frame-scale-factor. But pdf-tools needs a small work to support it. |
|
There seemed to be no need to do "a small work". (setq pdf-view-use-scaling t)You'll get criper pdf images. |
Thanks! It works! You are my hero! |
|
It looks to me like the latex-fragment are now rendering properly. Thank you so much for managing to fix it! |
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-geometryfunction inauctex/preview.elfile, which uses results ofdisplay-pixel-widthanddisplay-mm-widthto calculate the DPI and set the resolution of generated previews (command line arguments for ghostscript/dvipng). For my casedisplay-pixel-widthreturns 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?
The text was updated successfully, but these errors were encountered: