For a long time I worked in PD on a laptop with a third generation i7. And there was a problem that I attributed to weak graphics - a slow GUI. But, having bought a new mini PC, I encountered the same problem. I have a Ryzen 7 and the interface is still slow. I increased the buffer and tried to run Fix_PD (which, by the way, did not launch at 0.51 PD). It's quite annoying - moving objects, moving windows, connecting objects becomes torture for the eyes. And the interface of the PD is very simple, but there are such strange problems. Are there any new solutions?

GUI slows down when being updated at high rates.
This already might happen with a single GUI. Visuals / eyes do not require such a high update rate as sound / ears does. (PAL framerate is 25 fps)

so Pd can freeze with

[x]
|
[metro 2]
|
[o]

while metro 60 runs smoothly.

Without knowing your patch, into the dark: Separate GUI updates (with [set $1( message to GUI object) from audio modulations [*~]. Where GUI updates at lower rate.

[set( message makes sure the GUI is only set (here for visuals) without output.

First thing I try when dealing with fast incoming messages are [change] and some sort of [speedlim] before the GUI:
There are many different ones from different libraries, with the same name [speedlim], and some may be Vanilla abstractions, but not sure about this, - and as far as I remember, someone posted a simple Vanila speedlim in the forum just recently?

https://deken.puredata.info/search.html?libraries=&objects=speedlim&descriptions=

(wish Pd had build-in some kind of global speedlim for GUIs ...or would get rid of TCL)

@navu this could be another simple Vanilla speedlim:

Thank you! I'll try to experiment with this and report back.