How to cook as if some viewer was active?

Hello,
please is there some way of requesting cook on Container COMP that would cook it as if it had some viewer displaying it (even though it doesn’t at that time)?

I have a UI component that is kinda heavy and with its first display - it drops frames because more stuff needs to be cooked and prepared. When I display this component after it was displayed at least once, it doesn’t cause any computational overhead and the display is instant. Therefore I would like to cook it beforehand (when it isn’t actually visible) and know, it won’t drop frames when it is displayed for the first time.

Example:
Imagine adding super heavy basicWidgets into your scene while its viewer is still inactive. How could you prepare it so that it won’t drop frames when its viewer is activated?

Thanks :slight_smile:

The cook method of the OP Class has arguments to force and to include children:

cook(force=False, recurse=False, includeUtility=False)→ None:

Cook the contents of the operator if required.

    force - (Keyword, Optional) If True, the operator will always cook, even if it wouldn't under normal circumstances.

    recurse - (Keyword, Optional) If True, all children and sub-children of the operator will be cooked.

    includeUtility - (Keyword, Optional) If specified, controls whether or not utility components (eg Comments) are included in the results.

Thanks @nettoyeur, I have tried this, but unfortunately requesting recursive cook doesn’t cook the stuff needed for component’s actual display (I mean if it doesn’t already have some active viewer during this cook request; and if it does have some active viewer, you don’t have to request a cook).

You can try dropping basicWidgets in the scene and executing this:
op('/project1/basicWidgets').cook(force=True, recurse=True)
If you then activate the viewer on basicWidgets, it will still have quite expensive first display.

Yeah, if it’s the contents of a panel, there is a level of work that occurs when they are opened to do with building up the UI hierarchy and sizing everything within the window. It’s not something we can do as part of the cook. There isn’t really a way to pre-cache that other, than showing it. Sorry

Ah, it is a pity. I have been trying to find some way that would guarantee me the component will be prepared (and won’t cause frame drops when it is displayed on demand). I have tried couple “hacky” approaches (mainly centered around displaying the components or opening their viewer for a single frame on the start) but they weren’t really stable and eventually broke with very heavy components. Please would it be possible to introduce some stable way of performing such preparation in the future versions? Or do you have some idea on some hacky-but-stable approach that would guarantee me the component will be ready for display (no matter how heavy it is)? Thanks for help

Aha, I have found out why my hacky setup was breaking. Opening viewer for a single frame actually works nicely and prepares component for display, but it this somehow breaks when using replicator.

I have put together a simple scene where you can just activate viewer of basicWidgets for one frame (to prepare it) and then try clicking on its viewer - there is no impact when doing so. However when I try to do the same thing using replicator, it doesn’t work. I realized this is the problem I have been hitting.
test_r.3.toe (977.2 KB)

Here is a quick demo of what I mean, but since it was larger than 4MB I had to split it. Please feel free to remove dmp extension and unzip it.
2023-07-21 12-16-11.zip.001.dmp (4 MB)
2023-07-21 12-16-11.zip.002.dmp (1.5 MB)

Thanks and sorry for confusion, I haven’t realized replicator was causing this :slight_smile: