Also found this issue with 12.* over at the Natron forums. QT issues again. https://github.com/NatronGitHub/Natron/issues/712 [github.com] Maybe this issue can provide some insights?

There is sluggish and unusable. Here is my unusable issue with trying to move UV's in Houdini (the movie is really boring and doesn't show spinning beachball). After about three or four minutes, the UV's move a it before restarting the spinning beachball. My activity monitor shows CPU is 95% idle, so it isn't exactly taxing to a 2019 Mac Pro with pretty high specs. The same behavior is on the most recent production and daily builds. Especially bad is trying to load textures, change settings in materials and then rendering, adjusting UVs. The delays are in minutes, not seconds. Part of this is that the Apple Mac Pro 2019 really isn't good for 3D work, even with the expensive upgrades to the base model. I think it is more of a FCPX machine.
https://vimeo.com/672881792 [vimeo.com]

Island, I haven't been able to reproduce your issue on a Mac Pro 2019. Would you be able to attach your hip file so that we can take a look?

Sure:

Unfortunately I'm still not able to reproduce the issue. Is it consistent on your machine?

It is much better in 19.0.522 but again this issue gets bad after I've had Houdini open for awhile. Still not fixed.

Hi Rob,

I tried to set HOUDINI_DISABLE_BACKGROUND_HELP_INDEXING=1 but no success.

I suspect there is something going on with the event loop because if I use Houdini for 10 minutes and let it idle, it consumes a large chunk of CPU (25%) for the hindie process and 50% for the WindowServer process (Quartz renderer on macOS).
If you look at the Stacktrace, it continuously send message to the CA::Render even if Houdini is running in the background. That makes me think it keeps sending draw calls for some reasons. I compared to Cinema4D and Blender and I don't see these constant draw calls there.

Attached is the instrumentation.

Thank you

rvinluan

jd_m_007
I had reported the same @ https://www.sidefx.com/forum/topic/77342/ [www.sidefx.com]

Not sure if it's related to the problem but I know when it happens the number of QT widgets increase exponentially, like if there was some type of resource leak.

import PySide2.QtWidgets
len(PySide2.QtWidgets.QApplication.instance().allWidgets())

Yup. I saw your report when it came in through our support system. I gave this a try and I also noticed that the total number of widgets increased if I continually opened submenus in the TAB menu for example. However, when I continued to open submenus, eventually the total number of widgets dropped back down. I tested for about 5 minutes of opening submenus and the number of widgets stayed in the range of 80 to 120 widgets. It never got past that range.

I believe that is the expected behavior. Houdini doesn't immediately destroy windows (and the widgets that they contain) when the windows are closed. Instead it stores them so that they can be recycled or reused. By opening submenus quickly, that causes Houdini to create new windows since the old windows haven't completely been recycled yet. And then at some future point, Houdini does a garbage collection pass and flushes out the excessive windows.

jd_m_007
Another thing to note is that as soon as you startup Houdini, if you look at the CPU utilization it will stick to about constant 20% and force the windowserver process on macOS to gravitate at 60% of the energy efficient core on M1 on a constant basis and never goes down after that.
I assume it has to do with OGL draw calls. A similar problem was addressed in Blender and they switched from a NSOpenGLView to a CAMetalLayer @ https://developer.blender.org/T60043 [developer.blender.org]

Hope this helps.

P.S. Wanted to clarify it's a problem that has been happening since macOS Catalina so Intel as well

Interesting. Some of the user reports that I saw come in suggested that downgrading the macOS version "fixed" the lag problem. That suggested the bug only happened in Big Sur or Monterey. If you also see it in Catalina, then either the other users got lucky when they downgraded or maybe there's more than one issue at play here.

Thanks for the Blender link. I'll take a look. We don't create NSOpenGLView directly. We use Qt, which creates the underlying windows and views. Though looking at the Qt source code, I don't even see where it creates NSOpenGLView objects so maybe it already switched over to CAMetalLayer? I'll have to do more digging.

As for the 20% CPU utilization, can you try setting HOUDINI_DISABLE_BACKGROUND_HELP_INDEXING=1in your environment before launching Houdini? That will disable the help system's background indexing, which is notorious for chewing up CPU time when Houdini first opens. I just want to rule that out as the source of the CPU utilization.

Cheers,
Rob

jd_m_007
Hi Rob,

I tried to set HOUDINI_DISABLE_BACKGROUND_HELP_INDEXING=1 but no success.

I suspect there is something going on with the event loop because if I use Houdini for 10 minutes and let it idle, it consumes a large chunk of CPU (25%) for the hindie process and 50% for the WindowServer process (Quartz renderer on macOS).
If you look at the Stacktrace, it continuously send message to the CA::Render even if Houdini is running in the background. That makes me think it keeps sending draw calls for some reasons. I compared to Cinema4D and Blender and I don't see these constant draw calls there.

Attached is the instrumentation.

Thank you

Thanks. It's very possible that it's a redraw issue. I'm not ruling anything out. The call tree identifies the event loop as taking up majority of execution time but that's expected since everything runs through Houdini's event loop. It's interesting though that CA::Render is in the heaviest stack trace and that your CPU is pegged at 25% even when Houdini is idle. That's definitely not expected.

Unfortunately, I'm still unable to reproduce the sluggishness (I have no idea what I'm doing differently) so any concrete test steps you can provide is appreciated. Also, FYI, I'm in touch with our contacts at Apple seeking assistance to identify the cause of the problem.

Cheers,
Rob

I get several Houdini crashes each day. Usually things lock up with an evaluating python message. The license server routinely will not connect remotely and SideFx tech support does not know how to set up a local server despite several attempts. Unfortunately, Houdini is not reliable on a 2019 Mac Pro with production or daily builds.

It almost feels nondeterministic… I come to this crawl very fast if I try to do lookdev in redshift for example. The sluggishness comes crawling anyway but maybe if you try interacting with a 3rdparty renderer or going back and forth into lops a few times, maybe changing desktop latouts and sprinkle some wrangling on top.

Hi All,

I committed a potential fix for the sluggish viewport/UI issues on macOS. The potential fix is in tomorrow's 19.0.557 build.

jd_m_007was on the right track. The sluggishness was triggered by a resource leak. It wasn't detectable at the Qt level but rather at the system level. There was some rather old code in Houdini that triggered system window leaks in modern macOS versions.

Thanks to Matt McLin for providing a reliable way of detecting system window leaks as well as reproducible test steps!

Cheers,
Rob

Can anyone confirm that the fix above resolved the issue for them?

So far, not slow ups! Thanks.

Same here! And WindowServer not climbing in %CPU either. My thanks too.

Used 5-6 hours each for a few days, and it's been great! Huge thanks.