PdfViewer: Slow performance while scrolling a document with many Link annotations
While scrolling a document containing many Link annotations there is a decrease in the performance.
Posted on:27 Jul 2021 15:25
I confirm that the problem doesn't exist on my home computer (Surface Pro 3), but exists on all the computer's I've tried in my company. Because of the pandemic, I can only try the computers in my company through Remote Desktop. Do you think the problem can come from there? Remote Desktop uses different display settings. I will try different settings to see if it improves the performance. Is it something you can test on your side?
Posted on:27 Jul 2021 15:03
Unfortunately, the project you provided has the same problem, without any modifications. The CPU jumps to 25% (4 cores) and the GUI freezes because of that. The scroll experience is the same either I use the arrows (for small steps) or the thumb (for bigger steps). This is the same result regardless of the reading mode. I don't know if there is unnecessary display refresh depending of the the computer/monitor used. I can try on another computer to confirm. Is there something you think I can check on my computer hardware that can impact the functionality? I'm not the only user having this problem in my company.
Posted on:27 Jul 2021 14:34
I have attached the sample project I have used to test the performance issue. Could you try it on your end? There is a button in the toolbar used to switch the reading mode. Once you switch it, you have to open the PDF document again so that the changes can take effect.
On my end, in both modes, the PDF document you have provided scrolls pretty smoothly. Only in ReadOnDemand needs less than a second to load its content, but it doesn't block the UI. Here is a link to a video I have recorded while testing the performance: https://www.screencast.com/t/TgPqoL2k2.
Could you try to modify the sample project, so the performance issues can be reproduced and send it back to me?
Thank you for your explanation on what "Unplanned" means.
Unfortunately, we're already using "ReadAllAtOnce" and the problem is the same:
pdfViewer.DocumentSource = new PdfDocumentSource(new Uri(urlResult), PdfImportSettings.ReadAllAtOnce);
In that mode, I thought that the table of content would be slow to show the first time, but not every time you scroll over it. The important thing in that page is to show the text content without locking the thread. The "link" part can be done in background only if the user stop on that page. Is there a way to inactivate the links fore loading the document and activate them in code behind if the user stops on that page (or any other pages with links) while scrolling?
I'll check if I can load the document in memory first instead of using the URI, if it helps the performance. Also, I'll check if we can do something in MS Word to have less links in the table of content, since MS Word generates the table of content automatically. But we already have thousands of PDFs already generated so it won't solve the problem with them.
For example, ReadOnDemand keeps the memory footprint lower because the viewer keeps only a few pages in the memory and releases the others. When a page has to be visualized, it is read from the document and rendered, which causes the pages to renter their content on the go. We have tried to improve the performance by processing several different parts of the page in parallel and rendering them asynchronously, but still, sometimes it is a little bit slow.
On the other hand, the ReadAllAtOnce requires more time to show the document because the viewer reads the entire document and loads it in the memory. After that, rendering the separate pages is easier. Still, the memory required to load the entire document is more, and the initial loading time is more than ReadOnDemand.
Maybe the ReadAllAtOnce could be useful in your case.
This is a public item, and Unplanned is its status. It means that the feature request or bug report is not scheduled for implementation yet. Currently, I can not give you any particular timeframe for this performance improvement. You could read more on the statuses on the link here: https://feedback.telerik.com/aspnet-core-ui/status-info.
This is a show stopper for us since all our PDFs are generated with Microsoft Word and the second page is always the table of content with a lot of link annotations in it. When scrolling from the first page to the second page (and from the third page to the second page), the control freezes for 1 to 2 seconds, which is frustrating for the user who wants to go fast to page 3 and over. I've attached an example: the problem is present but less than in our standard PDF that have more items in the table of content.
I was wondering what do you mean by "Unplanned", since we're waiting for a solution to go live with the control. If the performance is not improve soon for that specific case, we need to find another way to display our PDFs in our applications.