I did some testing trying to figure out what are “fast” calls and “slow” calls. I tried using os.clock() but I don’t trust the values I got. However, I was logging to the terminal and the log prints an elapsed time since darktable started for every log line. So the output of my test looks like:
10.1816 LUA starting test run
10.1983 LUA test gui.action elapsed time for absolute adjust is 0.016851000000001
10.2201 LUA test gui.action elapsed time for get exposure value is 0.029548999999999
10.4871 LUA test gui.action elapsed time for relative adjust is 2.065055
An absolute adjust is just setting a value and it takes around .01 sec.
A get value about twice that or .02 sec.
A relative adjust (read the value, add an offset, then set it) takes roughly .25 sec.
How about the “set” routine does a check of the current value before applying the value and just returns if it’s the same? If it applies the setting, then wait for the pixelpipe-processing-complete event. The only things where that gets rough are comparing presets, because the return value is a number indexing into the list rather than a string so you need a table of the preset values to do a lookup and see if it’s a match.
I downloaded your earlier version of the script and looked through it trying to find issues. One thing I found is with darkroom-image-loaded. If the load isn’t clean, darktable will automatically try and reload the image so you don’t have to force a reload. Just discard the event and wait until it fires again.
The worst part of scripts like these is determining the state of the UI and the modules. That’s the reason for Workflow Automation with Lua Scripts · Issue #16722 · darktable-org/darktable · GitHub. Unfortunately I didn’t get very far with this for this release. I did manage to add get_active_preset() to libs, but I don’t have anything yet for iops (processing modules).
I’ll look at trying to figure out where the pixelpipe decides it doesn’t have to run and see if there’s a way to either send a pixelpipe-aborted event or even a pixelpipe-processing-complete from that point.
I have an action lib that is very much a work in progress/test bed, but the event handling works pretty well.
libaction.zip (3.1 KB)
I enjoyed reading your script. That’s the first time I’ve seen OO Lua. I also liked the debug.getinfo() thing. I probably need to go back and read the manual again to pick up more things I glossed over the first time I read it.
