Improved cache performance in full screen viewing

[Jensen Head]

When scrolling through a document, even if it's been open for an hour, the pages are rendered as they appear on the screen, not preemptively. This is a bit annoying. Please consider rendering at least a few pages ahead, with a save for when you access the document again during a single session.

Video — drive.google.com/file/d/1aOGOat3bTtBph9LC_7LEfJMj6_j2OscD/view

PDF-XChange Pro 10.43.391
Microsoft Windows 10.0.19045.5371

Possibly related topics —

• "Does Xchange has memory/cache dealing problem?" forum.pdf-xchange.com/viewtopic.php?t=39528 and
• "Memory + Disk cache issues" forum.pdf-xchange.com/viewtopic.php?t=29413

[Daniel - PDF-XChange]

Hello, Jensen Head

There is a careful balance between performing these tasks efficiently in real time, and not holding up the whole app while pre-rendering every aspect of something that could take 10 minutes to render in full. (before we consider rendering needs to happen at each zoom level, and when objects are moved around).

It is also worth saying that no matter how much pre-rendering is done, if you are scrolling through a content heavy document like this at the speed in your video, there almost always will be a moment when you catch up with any pre-rendering that may occur in that app, and then it can only do exactly what we are doing today, though in many cases, even more slowly.

I simply mean to convey that this is not a lack of consideration, we have been looking at these areas, and implementing improvements for a very long time. There will of course be improvements coming in the future, and they will be prioritized based on our Team's needs and availability. At the moment, revamping such a complex system is considered a "distant future" task, but small gradual improvements in the current method of handling are always ongoing.

As an extension to this, you could try using "Synchronous rendering" mode in the display options, that may help to mitigate the "gradual object pop-in" you are witnessing.

Kind regards,

[Jensen Head]

if you are scrolling through a content heavy document like this at the speed in your video

I very rarely view documents in smooth scrolling mode, as in the video. Much more often, I view what is currently displayed on the screen, and then scroll with the "Hand" tool or page turning / fliping. Regardless of how exactly I navigate to content that is not currently displayed (smooth continuous scrolling, fast scrolling with the Hand tool, or page turning), in the case of heavy documents, I always observe the loading effect. For the video, I chose the first scrolling method as the most clearly demonstrating this effect, and sped it up to save your time. If you need to provide a video of the other two methods with the same effect, I am ready to prepare them, upload them, and send links to them.

As an extension to this, you could try using "Synchronous rendering" mode in the display options, that may help to mitigate the "gradual object pop-in" you are witnessing.

Thanks for the advice! After switching the "Synchronous Page Rendering" setting to "Yes", I stopped seeing partially loaded pages, but scrolling became more jerky. That is, apparently, the page was blocked from displaying until its rendering was complete. When setting this setting to "Auto", scrolling was smoother, but pages might not display all the objects on them for some time.

When working with large documents (several gigabytes), I am ready to wait a few minutes after opening the document, just so that working with it would be more responsive. It's a pity that it doesn't work like that.

As I understand it, the workaround is to cut the document into many smaller ones (using the "Every N pages in Separate document" method of the "Split/Merge Documents" tool in PDF-Tools). But when working with a table of contents or a terminology index, you still have to work with the document as a whole.

[Daniel - PDF-XChange]

Hello, Jensen Head

Splitting the document wouldnt really help with either case there. The reason for the delayed pop-in is because that "Page" is heavy, and it takes time to render that content. Even if the document was smaller, the page itself would still be just as content heavy.
When synchronous rendering is disabled, instead it lets you view the page, before every element is loaded, which causes the gradual population as each item is loaded in order.

The only way to prevent this would be to freeze the application and render every page, or every nearby page, every time your zoom level changes... Which depending on the file (some technical documents ive seen take over a minute per page due to their complexity), could be quite a long time, and would arguably be a much worse solution than the current implementation.

As I have mentioned in other forum topics, pre-loading has most of the same issues as the current implementation, except it results in the application running more slowly for other operations while the pre-rendering for the next few pages is happening.
The only advantage that it really offers is if you are only scrolling down to look at the next page or two, that action should be a little smoother the very first time you do so, if you waited a while at the current page before scrolling. If at any point you need to scroll forward through more than just a small handful of pages, you will "catch up" to the pre-rendering system quite quickly, and then it will take longer to load that page, because it is also trying to load the next few as well.

We do pride ourselves with the speed at which we can render extremely heavy pages, and this is primarily possible because of the system we have chosen to use.

Kind regards,