Adding some more commentary.

#Expensive process forking in sxmo_hook_inputhandler.sh

This parsing

To get WMNAME and WMCLASS is fairly expensive, on my system it took 100ms, likely due to the several process forks happening here.

~aren had proposed in IRC a tweak of this type:

exec 0<<EOF
$(sxmo_wm.sh focusedwindow)
EOF
read -r WMCLASS
read -r WMNAME

echo "WMCLASS: $WMCLASS"
echo "WMNAME: $WMNAME"

Which treats the speed problem nicely, although looks a bit messy. For it to work, the "app:" and "title:" prefixes have to be removed from the output of sxmo_wm.sh.

#Expensive pidof in sxmo_state.sh

This pidof

In sxmo_state.sh is_locked as used in sxmo_hook_inputhandler.sh can be expensive. I have found that it can range from as low as 50ms to as high as 160ms or more. Perhaps we should save this information with a file, or otherwise somewhere in a state machine (could bonsaid "hold" this information...?), instead of searching the whole process table.

There has been some discussion about better ways to organize the state here.

#TODO: button events

There is probably some overhead the multi press timeout in bonsai / sxmo_multikey.sh, how much? See also #574.

#sxmo_appmenu.sh / sxmo_hook_contextmenu.sh

On the bonsai side, there isn't much extra latency. Except for the tiny unix socket initialization on client and server sides.

But we effectively feels a lot of latency, because the tree is designed this way. To emulate the behaviors we want, we have to wait a bit of time after most of the key events. Meaning single click start a timer after which, when no new events are received, we dispatch our scripts.

We could reduce the timeout duration (that I've increased a bit at some point). That could make the feeling better, but would also increase the difficulty to trigger the two-clicks.

Thank you for the reply ~stacyharper. Are you referring to the SXMO variable "$SXMO_THRESHOLD" here?

Not at all. This one is only used by the retro-compatible script.

Thanks for the write-up, I agree that this is an important area where we should really focus to optimize things a bit better, ideally without adding much extra complexity.

• Run a daemon that monitors the current window and precomputed as much as possible for the contextmenu / inputhandler. (I want there to be a better way, maybe we can optimize sway's ipc?).

I see what you mean. We shouldn't focus on just sway here though but find something that would also benefit dwm and the upcoming i3 and river integrations. An extra daemon that precomputes some things and holds some states might work. We have to be wary of things that continuously poll for state and perhaps take a more event-driven approach. As things grow I think the main challenge is keeping it as simple and clear as possible.

• Have lisgd execute actions before the touch up event. Proof of concept: https://lists.sr.ht/~mil/sxmo-devel/%3C20240508193041.334855-1-aren@peacevolution.org%3E.

Interesting experiment, I had missed that one. I wonder which of the existing gestures this would break adjustement (because they would fire prematurely).

• Update menus without closing and reopening them (#6)

Would be nice, but do any of the menu backends support such a thing?

• Evaluate conditional menu entries in parallel

Sounds good, I worry about the code complexity though... Also, if multiple cores start to fire up at once then some other background tasks may perhaps have a more noticable stutter? (I'm thinking about audio for one).

I made an attempt at cleaning up some of the low hanging fruit in the inputhandler -> appmenu -> contextmenu path, hopefully it's enough to be a noticeable improvement. https://lists.sr.ht/~mil/sxmo-devel/patches/57976