I understood that perform mode provides a way to render only a Window COMP and not the whole subsequent UIs related to the networkd which renders what we can see on the Window COMP.
Is it different from using a container with everything cooking inside, with all viewers disabled, containing an output that pops out texture to a Window COMP outside of the container and which I can see by right clicking and choose view which is giving me a floating window ?
I consciously pushing the understand of it far as I can imagine there is a difference…
Behind this question is the question of best practices for optimizing while designing a network.
I used to follow these rules for my project the.collapse:
disable all viewers not necessary (even those of CHOPs constant, which probably don’t get a lot of cpu works)
For this first project, for instance, I followed previous rules and I got a big container with one output, connected to a Window COMP, and I was viewing (right click view) on it and got the floating window, for monitoring visuals. Visuals were streamed through syphon to OBS. So I could also not even have the floating Window and monitor on OBS only.
Could it be a possible and efficient practice VS a container outputting to a Window COMP and this latter in Perform Mode ? What are the differences ?
I could add another question:
In case I’d need a couple of parameters to be controlled live by a custom UI, would it be possible to have 2 Windows COMP in perform mode? or should I collapse all I need (final visual to be displayed + UI elements) to the same window?
@julien
You are not far away from the goal
The technic I develop since a long time in TD:
– One Container Comp the size of my control screen, containing all my interface (setting and getting useful parameters, image of output before level, cue list etc), linked to the “perform” window
– the right number of base Comp encapsulating the main function, producing image, inputing controlers and signals, mapping images to volumes etc. and finaly some “final” null linked to outputs, audio device out, signal out and windows comp to beamers. I have two separate commands on my korg, one can open the beamers Window comps so I can see the output and the network, the second open the “perform” Window Comp in performance mode for the performance situation. Even with all the operators in hide mode, i can go from 50 fps to 60 fps when I activate the perform mode.
The nice and fun game is to build a powerful, nice and transmissible UI for the people in charge of conducting the peformance.
Have a nice day
The longer answer here is that much of the TouchDesigner network building interface is built out of TouchDesigner - and as such the interface for designing and creating operators has a memory cost that’s associated with working in “Designer” mode. A window COMP gives you handles and controls for manipulating a floating window beyond what’s available viewing a container - position, size, mouse behavior, full screen on a display, which display the window opens on, and on and on.
Your largest performance benefit will come form setting your project to “open in perform mode.” This allows you to pick the window COMP you’d like to open as a display / output for your project. When your project is set to open in perform mode, the designer interface will not be rendered or loaded when you start your project - that also means that all of the memory allocation that typically comes with the interface isn’t required (usually 200-400 MB of VRAM). This also means that none of your viewers are rendered or cached - which means that there’s no need for you to disable the viewers of your operators.
TouchDesigner is a pulled based system, and part of that mechanic means that there’s a very good chance that if something isn’t displayed on screen (or driving something that’s displayed on screen) that it’s not cooking.
When you’re in perform mode this won’t make a difference in terms of your project’s overall performance. This will make a difference when you’re in the network, but not if you can’t see the operators
More than a single window is generally not advised on windows because of how draw calls are handled - some of the guidance here may change as shading language instruction sets update. Depending on your hardware some users see their performance rate drop in half when they open a second window. Some GPUs don’t efficiently split instructions between windows, and the result is decreased performance. Some GPUs don’t see this particular issue - though if you’re looking to output a display that spans multiple displays, it’s very difficult to prevent tearing if you’re using more than one window.
