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:30 Jul 2021 13:04
I can confirm, that the WinForms PDF Viewer is not having the same performance issue. So if your clients are using your software with Remote Desktop it would be better to use the WinForms.
Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.
Posted on:28 Jul 2021 16:01
Thank you for taking the time to do all this and I'm glad you were able to reproduce the problem. Hopefully, in the future, it will help to improve your product, that is already pretty good.
Are you saying that the problem doesn't exist in a WinForm instead of a WPF application? I don't necessary need to use WPF.
Because of the pandemic, almost all my users are working from home (around 100), but the majority have laptops. I'll do a quick survey, and if the impact is only on few of us, I'll proceed with the deployment of the RadPDFViewer in the next weeks.
Keep me informed of any development on this in the future.
Posted on:28 Jul 2021 15:27
I have tried scrolling your document while connected using the Remote Desktop. The result is really slow scrolling. I have decided to try performance profiling the app. Here is the result of one of the profiling sessions:
I have selected the part of the timeline where I have scrolled up and down through the page with the Table of Contents. The strangest thing is the pie chart in the bottom right corner, showing that the app is idle 99.3% of the time.
I have tried different tools for profiling the application, and when profiling the CPU usage, I got this:
You could see that only 1.09% of the time I was scrolling went for the .NET part of the running app. I have found several reports of the same issue, and here is something interesting: https://stackoverflow.com/questions/1005497/improving-wpf-application-speed-over-remote-desktop. The PdfViewer uses DrawingContext to render each glyph of the text as geometry. We have found that this is the most performant way to render text from all fonts used in a PDF file. I have tried other controls we have that are using similar rendering techniques, and all are slower compared to using them on the local PC. The controls using UIElements for their UI are with better performance when using them through Remote Desktop.
Currently, we don't have an alternative rendering engine for the PdfViewer. Implementing a different rendering engine could be challenging, and there is little demand for that. That is why I can not provide you with any timeframe for fixing it.
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.