Pre-rendering not working; 100% CPU usage about pympress

[Cimbali]

Interesting, I'll take a look as soon as I can. Did you install with the binary installer? If so, the 32 or 64 bit version? If not, can you tell me your version of python?

[Cimbali]

Sounds like something is uninitialized for a while causing some trouble. Can't reproduce for now, with Python3.4 on Windows 7. I have a Windows 10 I can get my hands on, see if that helps.

[Cimbali]

Alright I haven't been able to reproduce this on Windows 10. I'm pretty busy right now but I'll try to devise some way to identify what's going wrong soon. I'll probably need you to run a modified version of pympress with a bunch of debug logging enabled, basically.

[Cimbali]

Alright, I received it and compared with running here on windows 7 and everything looks the same. No extra work in pre-rendering, you render 5 slides (x3 different-sized widgets) at the beginning and one when you change the page. That seems to fit with the memory and I/O statistics as well. So I think it's not the pre-rendering causing the problems.

I guess I'll have to look at what happens on page change and anything related to mouse events next.

[fefrei]

I did use the binary installer in its 64 bit version. (I'm running Windows 10.)

[fefrei]

I experimented some more, and reinstalled pympress (version 1.0).

It does make a difference whether pympress is started with a PDF file passed on the command line or whether it is picked in the UI!

Here are performance graphs for about 2 minutes after starting pympress with a PDF file:

For comparison, here is the result of starting pympress without a file, and selecting the (same) file after launch:

So here, CPU usage is still weirdly high (10 seconds / one core of CPU time for one slide), but it's no longer infinite 🙂

[Cimbali]

Alright, it was hard to reproduce since it only happened on the built binary versions for some unknown reason, but I think I've fixed it. Check it out here and I'll close the issue if you confirm it's all good.

[fefrei]

I'm sorry, but it looks like the behavior didn't change...

What I did notice: The CPU usage drops as soon as pympres loses focus.

[fefrei]

Even more weirdly: The high CPU usage occurs when switching to the next slide with the keyboard. It subsides as soon as the mouse is moved within any of pympress's windows.

[fefrei]

No problem – I'd guess that this is a race condition somewhere, making it hard to debug.
I'd be happy to help! (If it would help you, I could also try to provide process dumps during the high-CPU phases.)

[Cimbali]

Alright, it took me some time to figure out how to log from a built binary (since you can't just print).

Here's a (zipped) binary installer, that corresponds to the current tip of the debug_win10_prerendering branch, 8236527:

pympress-1.0.3-amd64.zip

If you run it with --log=debug you should see a file called pympress.log appear, with some verbose info on what the prerendering is doing or attempting to do.
Please confirm the bug is still happening and attach the file (maybe the pdf also?) so I can look for oddities.

[fefrei]

The bug is still happening, and I think I did a good capture. Here's what I did:

• started pympress with the arguments --log=debug talk-annotated.pdf
• on a third monitor, set up Process Hacker to monitor CPU usage
• pressed Page ↓ to advance a slide
• observed high CPU for about 20 seconds
• moved the mouse
• observed an immediate drop in CPU usage
• closed pympress be pressing Q

Here's the CPU usage graph during this test:

And here is the log file pympress.log, renamed to .txt to appease out GitHub overlords.

I'll send you an email with the PDF file to your Git email address in a second.

[Cimbali]

Hei @fefrei I read that drap&drop in Gtk might cause high CPU usage. To check if that is the case (and if you can still reproduce the bug), you could check out the debug/win10_prerendering branch where I deactivated the drag & drop functionality for testing purposes.

[fefrei]

Hi @Cimbali! I can still reproduce the CPU load in Pympress 1.1.1 (from the official MSI package). I'd be happy to test the debug version if you can build an installer for it again, I'm having trouble running it from source (which is most likely my fault).

[Cimbali]

If this is still reproducible, it would be interesting to look at the output of running GDK_DEBUG=draw,cursor pympress so we can see the events and identify which cause the high CPU usage.

[fefrei]

Hm, where is that output supposed to appear? The command terminates before the window opens, and I don't see a log file anywhere. (I installed the most recent version via the MSI installer.)