Intermittent stutter rendering many points

I am reviving up this thread, because although it is very old, my current problem seems to be similar. My setup is macOS on M1, Panda 1.10.11, and Python 3.9. I mainly visualise point clouds (1-2 objects at the same time, never fully visible, each for 200,000 points - I don’t know if it’s a lot or a little?). Points usually bold to a few pixels, plus a few Common Filters (but this, as I understand it, is processed in the GPU). Example below:


Generally it is smooth, 60 fps. But sometimes this fluidity gets cut (the refresh rate can drop to even around 30 fps). And this is not clearly related to what is happening in the image or in the code. What’s more, I can see quite a clear difference between launching the code from PyCharm (in which I am developing the application), and launching the code of the standalone built application. In the latter case, there are fewer fps trims.
Out of curiosity, I tried to set sync-video 0 in Config.prc and it turns out that normally, I can easily achieve 70-80 fps. Great, but what about it, when from time to time I still have, for fractions of a second, drops to 30 fps - very frustrating.
So I conclude that this is not a performance problem with my application, but an interaction with the operating system. For some reason, when something is happening in the background my application is losing CPU cycles. Is there any way to force an increase in the priority of my application? This is a real-time application, and really for the moment it is running, I don’t need any priority for all the junk that normally runs in the operating system in the background. Of course, theoretically, I could kill all these competing processes, or even install up a new operating system, but I would like any other user not to have to do something like that - let my application itself take the highest priority for the duration of the operation.
I tried a few solutions from the thread above, but without any visible, positive effects.

This is not necessarily so, I think–I would say that it’s still worth checking for potential issues within your game before concluding that the problem doesn’t lie there.

Specifically, have you used PStats to attempt to diagnose the problem? That might allow us to determine what, precisely, is happening when that frame-rate drop occurs.

If you’re not familiar with the use of PStats, see this manual page for more information on the matter.

1 Like

I split off your posts to a new thread - the thread you were replying to was 14 years old.

I concur that you need to drill into the problem with PStats so we can get a clue what system is taking up the time.

1 Like

Thank you for the answers and for separating the topic (I understand that I should not revive such old topics for the future?).
The use of PStats is definitely on my to-do list, however, as I understand it, its use must be preceded by compiling all or at least a part of the Panda3D package (I haven’t found the PStats binary package for macOS anywhere). As it does not seem so quick to do, I just decided to first “feel” the source of the problem, hoping for a quick “profit”.
In fact, I think there is something about process prioritization. I cleaned the operating system of various “junk” daemons running in the background, turned off active applications and after restarting the application launched from the build works decently, rarely dropping below 60 fps. The same code running from PyCharm works a bit worse.
But yes, I promise to investigate with PStats.

1 Like

One more thing - I noticed that top indicates that the entire application is running on a single thread. I found that Panda3D can be multi-threaded though, which would certainly give some chance to speed it up:
https://docs.panda3d.org/1.10/python/programming/rendering-process/multithreaded-render-pipeline
The problem is that the application, when trying to enable any multithreading, crashes as described here:

Do I understand correctly that this is some kind of bug and is it quite fresh?

I would strongly advise to look for the bottleneck before you start looking at multi-threading (which opens its own can of worms). Just throwing more computing power at a problem is a last-resort method that you should only use if we have attempted to eliminate the bottleneck in another manner (it may be quite an easy fix once we isolate it).

I regret that PStats is not available in the macOS build. If you have a non-macOS computer handy, you can run the PStats server on that computer and connect to it over the network.

Yes, that is a fresh bug that will be looked at soon.