memory surge after minimizing the vispy window

[neurochen]

Hi, thank you very much for working on vispy. Recently, I found a bug related to memory consumption. It appears after minimizing the vispy window, with a memory surge rate of about 50 MB/second. This surge doesn't exist even if you bring other programs to the top level. The only way to trigger it, based on my experience so far, is to minimize the window by either clicking the "Minimize" icon on the window or the taskbar icon of the vispy window.

Please try the two scripts provided in the Examples folder in the vispy github: Examples\demo\scene\scrolling_plots.py and Examples\demo\gloo\realtime_signals.py

Below is my environment:
OS: Windows 10 ver.1909
Python: 3.8.3
vispy: 0.6.4 or github master
pyqt5: 5.14.2

Thanks! Appreciate the help.

[djhoese]

That's...crazy. I got the same results when running the scrolling_plots.py example on my Ubuntu machine with Python 3.7. What seems to be the (obvious?) problem is that vispy, while being minimized, is telling the GPU to update with new data but since the window isn't visible the GPU isn't drawing it or PyQt5 is building up a queue of draws (or drawing events) and they're filling up memory.

Not really sure how to tackle this one. We might need to figure out first whether this is PyQt5 only or if this happens with other backends. Another thing to check would be to find out what is actually filling up memory.

[djhoese]

I did a quick test of changing the scrolling lines timer to a 5 second update interval and the memory increase is still there just much slower.

[neurochen]

Thanks, David, for quick responses. Just tried app.use() to change backends for the app. No surge for glfw and pyglet, but not for pyqt5. So, it's related to pyqt, which unfortunately is mandatory in my software. Could anyone fix the problem with pyqt5 backend?

[neurochen]

With pyqt5, it also uses much higher cpu as well. In my case, pyqt5 consumes 8.5% cpu, but pyglte only consumes 1.5% cpu. All these cpu tests were performed with the vispy window visible on the top.

[djhoese]

Could anyone fix the problem with pyqt5 backend?

So far based on your tests and my own tests I don't see anything that says this is something we (vispy) can fix ourselves. It's possible this is something in PyQt5 that we don't have control over. That said, I'm sure we can come up with a workaround.

In your application, are you seeing this because you have a timer that is updating the visuals? Do you have the option to not update the visuals if you detect that the window is minimized?

Regardless, someone (not sure I'll have time right now) could try playing with PyQt's process events (processEvents) in specific places in the timer function or in the backend to see if this fixes the issue. I wonder if telling Qt "I don't care that we aren't being shown, keep drawing stuff". There may be other Qt flags that control this logic so processEvents wouldn't be needed.

[neurochen]

I did playing with processEvents in the timer, but it didn't work out in the end. Currently, as you said, vispy updates are disabled once the window is minimized. Thanks.

[almarklein]

The problem is the GLIR queue :( - see #2092 for a fix.