The UI isn't threaded, leading to inability to reliably click buttons/sliders during rendering

[InconsolableCellist]

Problem: The UI becomes unresponsive during long render times, either due to the rendering or training steps. You can still click buttons but only with intermittent success, and the longer the render time is the more it seems like guesswork.

Expected results: The UI remains responsive regardless of the underlying tasks being performed. I.e., the UI should probably be threaded and any interactions you make with it will take effect during the next rendered frame.

Perhaps this is more of an issue for me because rendering takes 250ms with dynamic resolution and up to 15s with fixed resolution, as I'm on a Tesla M40.

Side note: This is quite an amazing project!

[Tom94]

Hi there, thanks!

Unfortunately, invoking the GPU simultaneously from two threads is non-trivial -- while the concept of "streams" is a thing in CUDA land, this would require running OpenGL shaders simultaneously with CUDA code, which, to my knowledge, enforces a synchronization point due to the context switch under the hood.

Bottom line: I don't think CPU-side threading would help much.

That aside, making all input buffered would introduce extra boilerplate/bookkeeping unless engineered carefully, which I'm willing to call "out of scope" here. I'm afraid I won't attempt it personally, but I would also not deny an external contribution that ends up managing it after all.

Lastly: dynamic resolution tries to keep the frame time to 50ms (not 250ms). Perhaps you're hitting the minimum resolution it'll do? It might be worth increasing the maximum resolution divider from 64 to 128 in the code.

[InconsolableCellist]

Thanks for the quick reply. I ended up testing this on my 3090 and the latency was so low it wasn't a problem at all. I think the M40 is really pushing the limits though, and it would be nice to have maybe a "render frame" button that will render up until the SPP and then uncheck "render frame" automatically. Perhaps that would be a good workaround.

I should've mentioned that I was able to render quickly enough using the minimum resolution divider (though the UI still required a lot of clicking and waiting without moving the mouse), but I wanted to see what a slower render would be like, which made it too hard to use the sliders and check boxes after starting it.

[Tom94]

For non-interactive training/rendering, the Python bindings really are the tool that should be used; not the GUI.

scripts/run.py gives an example of how to configure a headless testbed (all GUI options are available from the bindings), train for a set number of iterations, and rendering a frame with desired resolution/spp.

[MarcWeber]

I have render frames while training round about 2secs. It helps to click longer and release then UI works. Once training is stopped rendering is like 100ms and buttons can be clicked more easily. You just need to be as slow as the inner event loop I guess. Click, hold, don't move wait 4 secs release and button should be clicked ?