Forcing set to page action

[semenovnick]

Is this a feature relevant to companion itself, and not a specific module?

• [x] I believe this to be a feature for companion, and is not specific to a module

Is there an existing issue for this?

• [x] I have searched for similiar existing issues

Describe the feature

When working with complex setups with many pages/connections/variables and using action internal: Surface: Set to page pages on surfaces updating not so fast (sometimes even line by line) as I change it via companion settings in Surfaces tab or via TCP command. I explored the source code and noticed, that when using action like internal: Surface: Set to page it redraw surface in async way with setImmediate for safety reasons, as I understand, and in other cases- it triggers in sync way directly: https://github.com/bitfocus/companion/blob/ffb4de1ba40dbe35de42ff029e22f7285cd92eac/companion/lib/Surface/Handler.ts#L736-L744 Maybe it makes sense to add a Force Page Change checkbox in action to speed up page changing?

Usecases

To force page redrawing when it's a priority

[Julusian]

The reason for the delay when used from the internal actions, is so that other actions in the stack don't get delayed waiting for the surface draw to happen before continuing execution. This may be less of a concern with the more async way the surfaces draw now.

But I don't follow what the problem is with it being async like this. It will still be done generally as soon as the stack of actions has finished executing, so there should be no difference to it?
One thing I am wondering, is maybe you are changing the page of a single surface multiple times and we are performing the draw multiple times, so maybe we need some better logic to ensure we don't queue multiple of these deferred draws

So I am not sure if it would be a bad idea to give this option or not.

[dnmeid]

I'm open to improvements to speed up page changes but it feels to me that a force something checkbox is a bad idea. These are just workarounds for inferior design. The focus should always be to enhance the design, architecture, workflow.

[semenovnick]

I do not claim that synchronicity or asynchronicity is the root of the problem. However, there is a significant difference in the speed of switching pages using an action and when changing a page through under the same conditions. See the videos: via action:

https://github.com/user-attachments/assets/5279b874-d75b-430e-a4b1-74566fe001b8

via settings:

https://github.com/user-attachments/assets/37da683e-760f-450e-88bd-e2eec175248d

Sometimes switching through an action takes up to one or several seconds...

I would like to understand how to optimize the approach to the implementation of the project to reduce this effect.

Both actions in the code ultimately call the triggerRedraw function, so I assumed that the solution could be somewhere here. However, I understand that the solution I proposed in the form of a checkbox is an extreme and not entirely, to put it mildly, delicate method.

[dnmeid]

Did you try witht the fix from Julian in https://github.com/bitfocus/companion/commit/171846ac4f2a25d930900544d9e0ca45ed10a0f9 (latest beta)? Did it solve the problem for you?

[semenovnick]

Did you try witht the fix from Julian in 171846a (latest beta)? Did it solve the problem for you?

No. Performs in same way

[semenovnick]

I also noticed that when switching via action there is a jump in CPU usage, when switching via settings there is no CPU jump. Perhaps this information can help somehow.

UPD. As it turned out, the jump in CPU load is more likely associated with simply pressing a key than with switching pages, because I checked that even when simply pressing a key that does nothing in my loaded configuration, CPU usage increases sharply. Apparently, this is due to the fact that when you press any key, a check of all feedbacks is launched, which is naturally associated with computing costs

[Julusian]

Apparently, this is due to the fact that when you press any key, a check of all feedbacks is launched,

It shouldnt be all feedbacks, but just the ones that either used a variable that changed, or are affected by buttons being pushed. Our tracking of variable dependencies isn't the most optimal, it is a bit of a sprawling search. Is this an observation that it was checking them all, or just that it was checking many?

[semenovnick]

Is this an observation that it was checking them all, or just that it was checking many?

In my case, I have a lot (approx 10 pages with 4*24 buttons with feedbacks with variables that changing), I mean many... So many... Maybe there is way to disable feedbacks on pages, which are not showed on surfaces, for example?

[Julusian]

I'm not able to reproduce what you are seeing here.

I don't think that many feedbacks should be a problem, they will only be processed when companion decides they might have changed, a button press shouldnt trigger that unless there is a reason that press might affect them.

An export of your config would be helpful for diagnosing this any further. Either attach it here or email it to me [email protected]

[semenovnick]

I'm not able to reproduce what you are seeing here.

I don't think that many feedbacks should be a problem, they will only be processed when companion decides they might have changed, a button press shouldnt trigger that unless there is a reason that press might affect them.

An export of your config would be helpful for diagnosing this any further. Either attach it here or email it to me [email protected]

sent you an email with example of my configuration

[Julusian]

This is an interesting config to look at, its doing some quite clever stuff and by consequence is leaning into having many usages of a couple of internal feedbacks.
Those feedbacks are not operating as granularly as they could be, which looks to be the problem you are seeing.

Hopefully this makes your original case work better. (this is in the betas now, and will be in 4.0.2)

[semenovnick]

Thanks. In comparison to 4.0.0 it looks faster. Thanks!

Based on common sense, using this kind of feedback on each key is very resource-intensive for any approach or solution, but in my task, a 4x16(24, 32) key matrix, I actually need to update the appearance of the keys only when changing just a few variables for each row... and not all of these variables change frequently... there are a lot of ideas for optimization, and, perhaps, internal:Conditionalize existing feedbacks can speed up the process even more in future, if, for example, any feedback is ignored if the page, say, is not open on any of the surfaces...

[Julusian]

How is the speed compared to the settings based page change? I'm curious if that was everything or if there is something else worth looking for.

I dont think what you are doing is wrong, just that we hadnt done the little bit of work to optimise that feedback type.

But with the in progress graphics overhaul, you will be able to use an expression for every field, which could well entirely change the approach you take for this

[semenovnick]

Tried my production config with the new version 4.0.2 with your improvements. It's great! Page switching is now SIGNIFICANTLY faster and more responsive. This is a game changer. Thank you!