Pdf view very slow when multiple, unevenly split windows are displayed.

[acosmicjoke]

Describe the bug When pdf-view is open side by side with an other window in the same frame and the ratio of the widths is anything other than 1:1 I get around 0.4-0.8 sec lag in pdf view.

• No lag otherwise, this is on a modern laptop.
• The issue is still present using a minimal init.el file with only pdf-tools installed.
• If I restart pdf-view mode without changing the window configuration, the lag goes away.

The latter point makes me think that some internal variable connected to the width of the window needs updating, but I couldn't figure out which one.

Steps to Reproduce the behaviour Steps to reproduce the behaviour:

1. Open any pdf file in pdf-view mode.
2. Open an other buffer in a different window of the same frame such that the two windows are side by side.
3. Resize the widows such that their widths are not identical.

What is the expected behaviour? The input lag does not depend on the window size.

Desktop

• OS: Fedora linux
• Emacs Version: 29.4
• Poppler Version: 24.02.0-2.fc40

Your pdf-tools install

• pdf-tools Version: 20240429.407
• pdf-tools customization / configuration that you use: None in my test init file.

[aikrahguzar]

My guess is that (setq pdf-view-use-scaling nil) will cause your the lag to go away. Most likely the lag has nothing to do with window splits. Rather pdf-tools caches images and keeps using the cached images when the window size is changed. It just ask Emacs to scale the images to fit the window. This scaling probably causes expensive calculations on scrolling when the image dimensions are not integer multiple of display dimensions. Calling pdf-view-mode kills the local variable containing the cache and new images are generated at the correct dimension which explains why it fixes the problem.

If not turn on the profiler, use pdf-tools while it is lagging and post the profiles.

[acosmicjoke]

@aikrahguzar Thanks, you are right in that turning off scaling fixes the problem. I don't have a high dpi screen so, I'll just go with this solution.

Still, I'm a bit curious about what is happening here and I can't quite follow your argument. How is "half" an integer multiple of display dimension? Also, assuming the cached images are the problem, clearing them should make it go away right? However, when I delete the pdf image cache using 'pdf-cache-clear-data' (I'm hoping it does what the name implies) the problem persists. It sounds totally plausible that scaling the image is more expensive for certain windows dimensions than others, but I'm not sure about the mechanism.

Btw here is a cpu profile I got in my almost-empty init file. I didn't find it very helpful. 208 86% - command-execute 205 85% - byte-code 205 85% - read-extended-command 205 85% - read-extended-command-1 12 5% - completing-read-default 1 0% - redisplay_internal (C function) 1 0% - eval 1 0% if 3 1% - funcall-interactively 2 0% - pdf-view-scroll-up-or-next-page 2 0% image-mode-window-get 1 0% - execute-extended-command 1 0% - command-execute 1 0% funcall-interactively 28 11% - ... 28 11% Automatic GC 4 1% - redisplay_internal (C function) 1 0% menu-bar-update-buffers

[aikrahguzar]

@aikrahguzar Thanks, you are right in that turning off scaling fixes the problem. I don't have a high dpi screen so, I'll just go with this solution.

Still, I'm a bit curious about what is happening here and I can't quite follow your argument. How is "half" an integer multiple of display dimension? Also, assuming the cached images are the problem, clearing them should make it go away right? However, when I delete the pdf image cache using 'pdf-cache-clear-data' (I'm hoping it does what the name implies) the problem persists. It sounds totally plausible that scaling the image is more expensive for certain windows dimensions than others, but I'm not sure about the mechanism.

The actual image is the twice the size at which is it is displayed. The integer multiple is 2. If you clear the cache and then scroll (or otherwise go) to a new page, do you still get the lag on the new page? If the page remains the same no new image is requested.

Btw here is a cpu profile I got in my almost-empty init file. I didn't find it very helpful. 208 86% - command-execute 205 85% - byte-code 205 85% - read-extended-command 205 85% - read-extended-command-1 12 5% - completing-read-default 1 0% - redisplay_internal (C function) 1 0% - eval 1 0% if 3 1% - funcall-interactively 2 0% - pdf-view-scroll-up-or-next-page 2 0% image-mode-window-get 1 0% - execute-extended-command 1 0% - command-execute 1 0% funcall-interactively 28 11% - ... 28 11% Automatic GC 4 1% - redisplay_internal (C function) 1 0% menu-bar-update-buffers

Agreed, not very informative.