Severe UI instability with large library

[WhoIsMoloBartell]

Describe the bug An very unstable experience with large libraries (5k+ records), even on a high-end modern rig. Crashes inevitable within a minute.

To Reproduce Steps to reproduce the behavior:

1. Go to any interactive UI element
2. Click on that element
3. within a few seconds go to another element and click on it
4. Playnite hangs, then crashes in its entirety. Sometimes when restarting it will warn me that that crash was cause by a plugin, offering safe mode.
5. Throughout all these steps from 2 onwards, up to the crash, the UI responsiveness is very sluggish

Expected behavior Stability

Screenshots N/A, but please advise on what artefacts I can share

Desktop (please complete the following information):

• OS: Windows 11
• Version [e.g. 22]: Latest versions of all plugins, including theme modifier.

Additional context I am sure the problem is with EMixedNightMC as I have disabled all other UI extensions Disabling ThemeModifier did not improve stability much. I tried with eMixedNite and it was faster with the same sized library without the lag preceding the inevitable crash. Overall seemed much more stable than the EMixedNightMC fork. The crashes seem to happen when any new UI element(s) is/are presented to the user, through basic interaction (changing filters, changing a background, opening a game menu through edit on teh details panel. In fact the only place where it 100% doesn't happen is the Playnite menu itself. Even when using a small pool of records on screen (through the filter), crashes still happen

I would love to share some log files but I'm not sure where to begin. Any suggestions?

[defect1ve]

Today I faced this same problem and tracked it back to this issue and corresponding commit.

Reverting the changes made in that commit makes Zathura able to render different sized pages correctly again, but reinstates the issues originally reported (inconsistent page padding in some pages and fit commands fitting to largest image in the document).

Not sure what the course of action should be but personally I'd like Zathura to go back on that change and be able to render pages of different sizes without cropping. Maybe we could find other ways to fix the issues in the initial report.

Here's a before and after of reverting the change:

zathura 0.5.4

zathura 0.5.6 reverting the changes from that commit

[devensiv]

related to #436

Im still having this issue using 0.5.6 (OS Arch Linux) zathura --version

zathura 0.5.6
girara 0.4.4 (runtime: 0.4.4)
(plugin) pdf-poppler (0.3.2) (/usr/lib/zathura/libpdf-poppler.so)

my current workaround is downgrading to zathura --version

zathura 0.5.2
girara 0.3.9 (runtime: 0.3.9)
(plugin) pdf-poppler (0.3.1) (/usr/lib/zathura/libpdf-poppler.so)

[agguser]

For now, please revert the code so that it displays full (instead of cropped) variable sized pages! Or add a "mode" (specified using a command-line option or a key binding) that uses old-behaviour rendering.

A solution might be that each page has its own scale (retaining page's aspect ratio) to make all pages have the same width, resulting in no gaps between pages.

[9ary]

The aforementioned commit does indeed break documents with mixed page sizes completely.

Before (zathura 0.5.6 with the faulty commit reverted):

After (zathura 0.5.6, no patches):

GNOME Papers 46:

Sample document: https://www.st.com/resource/en/datasheet/stm32h743vi.pdf

As you can see, the only differences between Papers and zathura's old behavior are:

• positioning of the page within its tile/cell
• dynamic cell height

Otherwise, Papers renders all pages at the same scale, within in the same cell width, and all automatic zoom modes ("fit page", "fit width", "automatic") account for the largest bounding box, both in single and dual page modes.

In light of all of this, I concur with agguser: the change should be reverted, and the behavior can be refined from there to match other readers. There seems to be some confusion between this issue and #436, so going back to OP's request, this is a matter of letting auto-adjust modes adapt dynamically to the current page's dimensions, and/or adding an option to render pages with variable scale.

Edit: Okular's fit modes render pages with mixed scales.

[0re5ama]

I am getting this issue on 0.5.8