Allow panels to not trigger updates at input rate or let them run at project rate

Hey all, I’ve been struggling with performance issues and occasional frame drops when building native UIs in TD and I’ve recently been trying to profile my solutions. I found that input rate has a somewhat big impact in total load (in my case, mouse polling rate) and was wondering if this is a behavior that can / could be changed in the future. I’m sharing a project file where I count the events that are triggered via a panel execute for the insideu value, gather total load using the perform and analyze CHOPs and display all using an OP viewer. Moving the mouse over the perform window seems to trigger redraws (or some other load) in correspondence to what my mouse polling rate is set to up to 500Hz. Here are the results:

125 Hz:

500Hz:

1000Hz:

Here is the project file:
PanelCook.toe (4.3 KB)

By experience I’ve found that an immediate mode UI running at 60Hz (or even 30Hz!) is perfectly usable.

2 Likes

Here to emphasize someone should really take a look at this problem. It affects all sorts of things and isn’t clearly communicated either.

For example, check out this little physics demo, written inside of a Script CHOP

step_5_collision.tox (5.7 KB)

As you can see, the moment we start moving the cursor around on the panel, it ruins the timing of the physics. When checking, timeslicing is disabled, and there is no way to know that the chop is cooking multiple times per frame besides the behavior observed.

In the end I managed to mitigate it with

if scriptOp.cookedThisFrame:
		return

Though it would have been nice to have better grip on whats happening here.

2 Likes

I’d for sure wish for more control over this, particularly when it comes to user input, it looks like even Widget COMPs and their embedded TOPs will cook multiple times per frame if you have a high polling device interacting with the window.

1 Like