The Clone mode in DVO Fix is a tremendously useful tool but it is also the culprit for many issues and it is a brutal time hog.

Oftentimes when I click a clone brush in a frame for the first time it takes upwards of 3 seconds for the program to respond. And this is on a 24-core i9-13900K processor running at 5.6GHz with 128GB of RAM and a completely M.2 SSD drive-based configuration. Curiously, subsequent brush clicks in the same frame are processed instantaneously, so it seems to have to do with the initialization/instantiation of the effect in the frame itself.

The culprit seems to have to do with the complexity of the frame itself. My assumption is that Phoneix is breaking the frame down into geometric shapes/highlights/sections it recognizes so that it can track, identify, and manipulate them. The more objects it detects, the higher the workload.

All that is natural, but a 3-second delay is not. I think one of your senior software architects should take a really good look at how these objects are managed and how they are accessed. Perhaps a number of BSP trees would improve things, each using a different, narrowed sorting approach so that a click can very quickly identify the affected object without having to go through hundreds of potential candidates that end up being discarded.

Or perhaps some of the time-consuming initialization could be done ahead of time in the background, before the click. If I have a DVO Fix layer active and I switch to a new frame, the software should assume I may be making a brush click and be preemptively prepared by the time I do. If there is no click, discard the initialization data or save them in case I return to the frame at a later point.

Or perhaps your list handling itself is just ineffectively implemented. I don't know. I would have to look at the implementation of how you manage these objects, but I have absolutely no doubt that there would be enormous room for optimization and improvement, especially since Phoenix never seems to use more than 64GB of memory. This means I have a full 64GB of memory still available to store look-up tables and trees that could potentially speed up processing.

Why is this important? Because the time I spend waiting for DVO Fix to apply its effect can amount to over an hour every day!

Here's another way to think about this. An average movie has about 150,000 frames. If you introduce only a single second of delay per frame into the workflow, this amounts to 150,000 seconds. That's over 40 hours! A whole week's worth of work! Any kind of delays have a significant impact over the course of a project and for that reason, the program's responsiveness and any kind of methodology that can alleviate delays/waits, reduce the number of clicks, limit the necessary mouse movements, and make the overall user experience faster, should be at the top of your priority list—and that should include customizable hotkeys for virtually every button.