Takuma Miyamoto

Sorry to reply to my own post — rereading the forum, this thread was actually very close to my symptoms, and might share the same root cause:
https://www.sidefx.com/forum/topic/77342/ [www.sidefx.com]

It's from a few years ago, but it seems no reliable reproduction steps were ever found [www.sidefx.com].
I hope info here like the monitoring tool and repro steps can help with that.

*Note:
I know this isn't the place to report bugs, but I just want to check if anyone else is also seeing this.
I reported it to support about two months ago and was told they would "discuss this issue with our developers" — but I haven't heard anything since.
If anyone has managed to resolve this, I'd love to know how.

---
Hi. After working in Houdini on macOS for a while, I started noticing significant input lag. Similar issues have come up in this forum before (like here [www.sidefx.com] and there [www.sidefx.com]), and I wondered if those were recurring — but the symptoms seem a bit different this time.
Here's what I've observed so far:

• Lag begins after roughly 15–30 minutes of use
  
• Only drag operations are affected — others (like animation playback performance) aren't unaffected
  
• All drag operations are affected: viewport navigation, node network panning, etc.
  
• Initially only fast mouse movements are affected, but it gradually worsens at normal speeds too
  
• The symptoms appear regardless of which nodes or features are used in the scene
  

The most painful part is that basic viewport and network navigation becomes difficult.
Oddly, slowing down the mouse movement helps — and I caught myself unconsciously doing exactly that.

---
The following includes some speculation on my part.

While trying to reproduce the issue consistently, I noticed a possible connection to invisible windows left behind by Houdini. macOS seems to allow external tools to query the windows registered with the window server (via CGWindowList) — their count, position, and size — so I built a small Python menubar app to do just that.


*This shows Houdini has created 458 windows, but only one is visible.
*Several other tools are running in the screenshot, but the results are the same with a minimal setup.

When the lag is at its worst, Houdini has accumulated a large number of invisible windows. These increase with virtually every UI interaction — opening the Tab menu, clicking a SOP node to show parameters, pressing D to open display options, and so on. Other apps also create and destroy windows during normal use, but unused windows are typically discarded. Houdini's process only ever accumulates them.

According to an AI assistant, even invisible windows are subject to hit-testing on every mouse drag event — which would explain why slower mouse movement reduces the symptoms. (I can't verify this myself, but it does seem to fit.)

To test this theory, I tried reproducing the issue from a fresh launch by rapidly toggling the Tab menu repeatedly. The lag appeared even on a completely empty scene. The rate at which it progresses seems to vary with environment (such as resolution of the connected display) but it provides a reliable way to reproduce the issue. Here's a recording:



---
This problem isn't limited to any specific project or feature — it occurs consistently whenever I use Houdini on macOS, and I consider it quite critical.
I also use Houdini on Windows and Linux regularly, and neither platform shows any sign of this issue.

If you're experiencing the same thing and want to investigate, I've attached the window monitoring tool below. It's a single Python script — you may need to install a couple of packages, but that's all.


Thanks for reading.


Tested on:

• MacBook Pro(Apple M3 Max, 128GB)
  
• macOS Tahoe (26.5.1)
  
• Houdini 21.0.671, 21.0.729
  

@cwhite
Thank you for the advice! This was really helpful.
As you mentioned, I didn’t notice the relationship with the translation limits.

I also think I now understand the concept: it’s not the actual “Motor” (the rotation anchor) that translates, but the constraint itself.
And the Motor is like just a additional soft constraint goals setting for position & rotation, rather than actual "Motor".
This is exactly what I was looking for! (as I mentioned in the background).

Now I can tightly constrain its position along a single axis (by increasing the stiffness of the Translation Limit),
while keeping its position with a bouncy effect (by lowering the damping of the Motor Position),
all within a single constraint relationship.

Thanks again for sharing your knowledge!