Deferred Lua Execution

[geringsj]

This PR restructures the Lua resources to provide a deferred lua execution method, such that services and the CLI can queue lua commands which get executed at one single, foreseeable point in the main loop.

Summary of Changes

• add and use LuaScriptExecution and LuaScriptpaths resource structs
• LuaScriptExecuton allows immediate and deferred execution mode
• in main(), twice a frame the lua queue gets processed: before RenderNextFrame(), and inside RenderNextFrame() before rendering of entry points (after services possibly issued lua commands)
• Project Loader, GUI, Remote Service and main() moved to use deferred lua
• CLI inputs (project files, raw lua) can be executed in same order as passed via CLI

References and Context

This refactoring streamlines the Lua execution logic in the program, getting rid of project file and CLI Lua inputs confusion. This allows, for example, to load a project file and directly alter parameters of instantiated modules via CLI. At the same time, when taking control over the main loop via a lua project file, we remain outside of RenderNextFrame(). For the GUI, this allows for a strictly data-driven GUI re-design, decoupling of GUI event handling (before rendering of the frame) from rendering of the GUI draw list.

Challenges

// main render loop
while(run) {
execute_deferred_lua();
   {// RenderNextFrame()
      services.start_frame(); // e.g. resource update
      execute_deferred_lua();
      render();
      services.finish_frame();
   }
}

To keep the Lua execution outside of a frame, we need to flush the Lua queue before RenderNextFrame(). However, because services can issue Lua commands too (incoming network messages, keyboard/mouse + GUI inputs, resulting graph changes), Lua also needs to be flushed after service resource updates/digestion and before rendering of the graph. Having two Lua flushes leads to problems, e.g. Lua scripts coming from network get executed inside a frame, which is problematic when they contain mmRenderNextFrame(). However, not executing Lua after service updates ignores latest rendering state inputs for one frame, which seems even worse.

Test Instructions

CLI project files, param changes, lua execution, order of lua commands is respected: ./megamol.exe -p ../examples/testspheres.lua --param ::data::numSpheres=100 --param ::view::anim::play=true -e "print(\"\n\nHello MegaMol\n\n.\"); print(mmHelp())"

Load other project file after 500 frames: ./megamol.exe -p ../examples/testspheres.lua --param ::data::numSpheres=100 --param ::view::anim::play=true -e "for i = 1,500,1; do mmRenderNextFrame(); end; mmClearGraph()" -p ../examples/infovis-spheres.lua

2023-04-17-18-33-06_Trim.mp4

[reinago]

how much stuff has to actually run before services? could we get rid of the first execute_deferred_lua(); ? this feels a bit off tbh.

[geringsj]

When a .lua file wants to take control over the render loop it would be nice to execute that lua code before entering RenderNextFrame(). Or we find a way to abort a started frame and ensure nothing breaks (e.g. profiling) when executing mmRenderNextFrame() from within RenderNextFrame(). Until now this is handled in main() by executing project files before entering the main loop. Am 27. April 2023 13:34:58 MESZ schrieb Guido Reina ***@***.***>:

…

how much stuff has to actually run before services? could we get rid of the first execute_deferred_lua(); ? this feels a bit off tbh. -- Reply to this email directly or view it on GitHub: #1180 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>