Perform / focus for graphics-only process

I have a main Touch application that switches between graphics sources - some oFx over spout and one other Touch source. On the other Touch source I’m doing a GLSL Multi sim and and render with a bunch of post stuff.

I want the other Touch graphics process to run optimally, but it can’t be in perform mode as the main Touch application is the one drawing it to the window (after receiving its result over Touch In/Out TOP connection.

I find that minimizing it gets much better performance than leaving the network editor up, but is there some better, less fragile way to keep that instance in focus and let it draw only its output to the Touch Out TOP it’s connected to?

I tried running both instances in perform mode but they’re overdrawing each other and I’m getting a big performance hit.

I thought I knew the best practice on this but it turns out I only had part of the picture.

in your Perform Window COMP, disable the parameter “drawwindow”.
When disabled the window will not update it’s contents at all. Useful for processes that arn’t doing rendering such as Audio or networking processes, or for when using VR devices.

Thanks, Idz, but I am drawing in both. One I’m just using the result to send to another network, though, not draw to screen.

The parameter is exactly for not drawing to screen as you say.
I use it in all my VR applications who render a lot, but not to the screen.
Helps performace a lot.
Try it!

When I disable Draw Window in the window comp that controls perform mode in my ‘graphics’ instance, the feed coming via Touch In/Out into the ‘main’ instance freezes, which is consistent with what I would expect.

I feel like I’m missing a part of this configuration, or I’m not communicating clearly, or I’m trying to do something that she don’t wanna.

Instance A → render, generates an image → Touch Out
Touch in → Instance B → logic and image switch → draws to screen

How do I get Instance A to run in perform mode without drawing to screen but still cooking and sending its image through the Touch Out to Instance B?

Ah, I would have thought a Touch Out TOP always cooks by default. I use this case for VR and the VR TOP does always cook.

On mobile now so can’t make you an example, but there is a parameter in the Touch Out TOP “alwayscook” which forces the TOP to cook every frame.
If there would not be, you can always place an Execute DAT to force cooking of your last node(which forces the whole chain to cook, because TD is a pull-based system) with code like this:

def frameStart(frame):
    op('mylastnode').cook(force=True)
    return

Thanks, Idz! I’m with it now - what I realized is that I think perhaps the ‘Always On Top’ par of the Window comp isn’t working the way I thought?

In my ‘graphics’ process that flag is disabled on the perform Window comp. In my ‘main’ process, it’s enabled, but what determines who draws on top is the order in which I kick them into perform. The latter instance to be set to perform draws on top.

This was causing my ‘graphics’ instance to draw on top of my ‘main’ instance, so I was seeing a static frame.

Does this sound like the expected behavior or is that a bug? 12100, Win 10, GTX 980M.

Hey noah, I can’t duplicate that behavior here, I’m also on 12100, win10, 970 GTX, nvidia driver 385.28.

Attached a background_send.toe (which has drawwindow = False, and has a Touch Out TOP) and a receiver.toe which has alwaysontop=1. They both start in perform mode.
No matter in what order I start the files, the receiver is always on top. Receiver is just a black screen when the sender has not started yet.
background_send.2.toe (3.86 KB)
receive.toe (3.73 KB)

Idz’s approach is correct. We usually take a hotkey and turn it into a toggle that runs True/False on this

ui.redrawMainWindow = False

Which is essentially equivalent to perform mode minus opening a new window. So then you can just leave the process sitting open in the background and it’ll look like it’s frozen if you look at that process, but it’s running and you just put your main (and only perform window) over top.

THE MISSING LINK!

Thank you both!

Would love to see this technique documented in the wiki … feel like it’s Important and Singularly Right enough to be canon.

Hmm, just realized its not in the book. But I have been showing the techniques at workshops, I think the project file at this repo link named “redraw.toe” is an example…unless I’m really terrible at naming things…

github.com/nVoid/LA-intermediat … em%20setup

Leaving it here for further reference incase anyone needs an example and finds this thread.

Hey Noah, are you able to send your .toe files to us at support@derivative.ca? Your original solution should have worked. The Touch Out TOP should force cooks without having to do anything special, even if it’s not visible. Unless you have the Cook Always parameter turned off. It’s on by default

I’ll mention that the ui.redrawMainWindow should not be needed anymore, since you can set your window to not redraw in the Window COMP parameters. That way you can just open in perform mode with the Window COMP like that.

Thanks, Malcolm - it’s been a bit and I’d have to do a bit of digging to find the version of this project that had this configuration. I’ll see if I can get to this this week. Meanwhile, I’ve disabled the redrawMainWindow flag on startup in that graphics process, which takes the load off from that instance except for the needed cooking in the chain.