Optionally suppress button text expression evaluation if a page isn't being rendered

[TodWulff]

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

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

Is there an existing issue for this?

• I have searched for similiar existing issues

Describe the feature

Having dug through historical/current issues, I perceive that there isn't one that aligns with the intent of this feature request.

In Companion, my use case (one of near infinite, I acknowledge, hence feature vs. bug flag), I am implementing a surface that controls a VoiceMeeter instance on a headless server. In my case, it's VM Potato (8x8) (VMP) on an older x64 Windows 11 box.

I've a page for each source/bus and, thereon each page, I have all of the others selectable to enable bouncing from one strip to another in an easy/intuitive manner. I've elected to express current VU levels on all of those source/bus buttons. The net result is some 304 buttons spread across some 20+ pages of 10x10 surface buttons (thus far).

With the example button text expression depicted below (admittedly expensive), with no conditionals, Companion ends up consuming an obnoxious amount of CPU cycles (N of 60% (an older (circa 2015-ish) box, admittedly) - when streaming with the short-circuited evaluation suppression, average load is bouncing around ~40% - when I initially implemented the level display for all source/outputs (no conditional evaluation), it grew to a static 100% (with other implications, of course)).

After some dialog with our AI brethren, it was suggested that I wrap the expensive expressions in a conditional to see if the expression conditional would short circuit and suppress evaluation of the false branch. Thankfully, the expression evaluation engine did just that and resource consumption is again reasonable/deterministic and intentionally controllable.

In the course of this endeavor, I perceive to have determined that all button text expressions are being evaluated even if they are on pages that aren't being rendered. I find that an option to disable this behavior (suppressing button text expression evaluation if a page isn't being rendered) might be useful. This is the topic of my feature request.

Expensive Expression wrapped in a conditional:

$(internal:surface_emulator_JmQSxl782YQvxzenPry_4_page) == $(this:page) ?
//expensive expression start
concat(
  getVariable(
    'internal',
    concat('page_number_', $(custom:VmpStripGrp)*10 + $(this:row)-1, '_name')
  ),
  "\n",
  round(parseVariables(concat('$(VMP:strip_', $(this:row)-1, '_l1)')), 0),
  "|",
  round(parseVariables(concat('$(VMP:strip_', $(this:row)-1, '_l2)')), 0),
  "\n"
)
//expensive expression end
: ""

(As an aside, is there a more broadly applicable (elegant) way to accomplish the conditional test (removing the specific reference to a surface)? Not being a dev, and new to Companion, I'm no where near competent enough...)

Thanks!

Usecases

Being able to deterministically suppress evaluation of non-rendered button text expressions would be of potential use to keep resource consumption under control on the Companion host PC.

The potential set of use cases is broad (from my ignorant perspective... :)).

Screenshots of my WIP VMP control surface implementation, to give a visual frame of reference:

[Julusian]

I suspect that it isn't the expressions being the costly part, but that we are rendering every button, even when it is not being viewed.
And your expression change is causing the expression to either be evaluated less often (causing less renders), or return the same value more often (causing a cache hit, avoiding a redraw)

Off the top of my head, I don't know how viable it is to avoid this drawing. But of course changing this would mean that changing pages would be slower, while it catches up with drawing everything. Doesn't mean this can't be done, just a side effect to be wary of

[TodWulff]

Understood. Your assertion about anticipated side effects affirms what I am seeing, just rooted in the graphics generation vs. expression evaluation.

As info, with the newly implemented approach (conditional wrapping of the expression), there is some observed latency from the page rendering until the buttons' text fully populates - w/ my slow host box (and the surfaces being connected via wifi), I am seeing about 0.5s to 0.75s from a new page command until the page fully renders (framework and any unwrapped buttons display right away) and all of the conditionally-wrapped buttons populate (after the expressions do their thing).

For my use case, this is a small price to pay for giving the host machine some headroom to support OBS camera video ingestion, scene compositing/rendering, and serving multiple streams (along with VMP doing it's thing).

Regardless, thanks for considering it. You guys rock. Take care.