Home / Resource usage when at end/beginning of file

Hi all,

First of all, thanks to everybody in this community for the development of SumatraPDF! I have been using it for several years now and I’m very happy about it: slim and fast.
Today I noticed that when I’m scrolling trough a PDF, I can see my GPU usage go up when I am scrolling, which perfect sense.
I noticed however that when I reached the top/bottom of the page and keep scrolling, the GPU usage stays high. The view does not change, since there is no new content to load, but somehow the GPU keeps rendering the same view. I would have expected that when I have reached the top and keep scrolling, the view would not be rendered. It’s a minor thing and not really an issue, but I thought it might be worth sharing.

Kind regards,

Rik

I’ve never done such profiling. Can you share your methodology i.e.:

• what software do you use for gpu profiling
• how do you determine GPU activity comes from Sumatra and not other software?
• which version of Sumatra did you profile
• what hardware did you use to profile (i.e. which GPU card)
• which OS version?
• does it happen with every PDF or just one?

Sumatra doesn’t directly use GPU. Whatever GPU activity it’s there must be caused indirectly from using Windows API and we’re not doing anything advanced there either.

I wouldn’t expect any GPU activity once we stop rendering but I won’t exclude that possibility. Would have to dig deeper but like I said, so far I haven’t done GPU profiling at all.

Hi Krzysztof,

Thanks for your swift and elaborate reply. I dug a little deeper based on your questions. The problem only seems to be occurring when scrolling with a touchpad.

System: HP Elitebook 8570w, NVIDIA Quadro K1000M graphics card.
OS: Windows 10 Pro x64, Version 1709
SumatraPDF version: 3.1.2 64-bit (latest)
PDF: any PDF I tried showed same behaviour

I do not have any SDKs/toolboxes available for advanced profiling, but Windows has a built-in profiler nowadays. I have no strict evidence that the GPU activity is from SumatraPDF, but the GPU usage and scrolling are clearly correlated, as the attached image below shows. Actually, the CPU usage comes from SumatraPDF, and the GPU usage seen in the graph is caused by an instance of csrss.exe, so indeed this likely has to do with the Windows API.

I performed the following test:

1. Close all other apps, make sure that nothing is running in background.
2. Scroll through the PDF file until the top is reached, and stop when the top is reached.
3. Wait for a few seconds, and “overscroll:” continue scrolling up, although PDF is already at the top.

See the usage graphs here: https://imgur.com/a/68VYH

Finally, I think the most important observation is that this only happens when I use multitouch gestures on my touchpad for scrolling. I tried the same thing as described above when scrolling with a mouse or by pressing the middle mouse button and dragging, but in both cases CPU/GPU went down to zero when the top was reached. It seems to be something that only happens with the touchpad.

Not just that, it may also be something specific to your brand of touchpad, or current driver version. Synaptics, Elantech et al aren’t particularly known for stellar driver quality. As kjk said, more testing on a variety of hardware would be required to confirm that it’s actually something that needs to be fixed in Sumatra.

Thanks for you reply Peter. I do not have any other touchpads at hand to verify; but it might indeed very well be that it is the driver that keeps sending scrolling commands even though the top of the page has already been reached. One again, it is not a problem at all during normal usage, I was just curious and thought it might have been worthwhile to mention. Thanks again for the response!