Hello Daniel,
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.
Regards,
Nikolay Demirev
Progress Telerik
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/.
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.
Hi Daniel,
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.
Are your clients also using remote desktop?
Regards,
Nikolay Demirev
Progress Telerik
Love the Telerik and Kendo UI products and believe more people should try them? Invite a fellow developer to become a Progress customer, and each of you can get a $50 Amazon gift voucher.
Hello Daniel,
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?
Regards,
Nikolay Demirev
Progress Telerik
Love the Telerik and Kendo UI products and believe more people should try them? Invite a fellow developer to become a Progress customer, and each of you can get a $50 Amazon gift voucher.
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.
Hello Daniel,
The PdfViewer has two different reading modes - ReadOnDemand and ReadAllAtOnce. The default is ReadOnDemand, but both of them have their pros and cons. Here is the link to the documentation article on the topic: https://docs.telerik.com/devtools/wpf/controls/radpdfviewer/showing-a-file#specifying-reading-mode.
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.
Regards,
Nikolay Demirev
Progress Telerik
Love the Telerik and Kendo UI products and believe more people should try them? Invite a fellow developer to become a Progress customer and each of you can get a $50 Amazon gift voucher.
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.