WPM Luna animation freezes while typing when fixed bottom modifier indicators are enabled (nice!view / nice_epaper)

[kervin5]

Hi. First of all, thank you for this repo/project! Amazing work!

I'm on a Corne with nice!view (corne_left nice_view_adapter nice_epaper), ZMK v0.3.0, zmk-nice-oled at 46f824a.

I'm trying to run WPM Luna + the WPM graph + the fixed bottom modifier row (horizontal symbols). Everything works except one thing: Luna stops animating while I'm typing and only looks normal again once I stop. The bottom mod icons themselves seem fine.

A few things I tried to narrow it down:

Turning off the WPM graph (WPM_GRAPH=n) didn't help
Turning off the bottom fixed modifiers (MODIFIERS_INDICATORS_FIXED=n) did fix Luna
So it feels specific to the bottom row + WPM Luna combo, not Luna in general (modifier Luna on its own hasn't been the problem in my testing)
Config on the left/central half, roughly:

CONFIG_NICE_EPAPER_ON=y
CONFIG_NICE_OLED_ON=n
CONFIG_NICE_OLED_WIDGET_WPM=y
CONFIG_NICE_OLED_WIDGET_WPM_LUNA=y
CONFIG_NICE_OLED_WIDGET_WPM_GRAPH=y
CONFIG_NICE_OLED_WIDGET_WPM_NUMBER=y
CONFIG_NICE_OLED_WIDGET_MODIFIERS_INDICATORS=y
CONFIG_NICE_OLED_WIDGET_MODIFIERS_INDICATORS_FIXED=y
CONFIG_NICE_OLED_WIDGET_MODIFIERS_INDICATORS_FIXED_SYMBOL=y
CONFIG_NICE_OLED_WIDGET_MODIFIERS_INDICATORS_FIXED_HOR=y
I poked at screen.c and noticed the fixed modifier listener is on keycode_state_changed and calls draw_canvas() (which does rotate_canvas()). WPM Luna also lives on the canvas. My guess is that hammering the canvas on every key while typing starves the animimg on nice!view's 1bpp display — but I'm not 100% sure, and disabling the graph alone didn't change the behavior, which confused me.

I also tried a pretty big local fork (overlays, moving Luna off the canvas, filtering the modifier listener, etc.) and it still froze on device, so I reverted and wanted to report upstream instead of maintaining that.

The bottom row is genuinely useful for seeing Shift/Ctrl/Alt/Cmd at a glance on such a small screen — I'd love to keep it and Luna. Happy to test patches or provide logs/video if that helps.

Thanks!

[HenryHu]

I think I've hit a similar issue. The more obvious problem on my side is - with modifiers indicators enabled, every type pauses my rgb underglow for a short period of time - not very long, maybe 1/4 of a second or so, but that seems sufficient to impact both rgb and display.
I'm not sure if the controller is too slow - but seems like that the modifiers indicators involve very high processing cost per-key.

[HenryHu]

as you suggested, if I just comment out draw_canvas() in set_mods_status(), it seems to resolve the issue for me. The mods icons still get updates - so it still seems to be working.

[HenryHu]

I think my pull-request partially resolves the issue - at least when you're not pressing modifiers.
When you're pressing modifiers, it's still as slow as before - which I suppose is because draw_canvas() itself is slow.
Honestly, most of its work is wasted: it redraws everything, whether they changed or not.
Possibly everything should be split into their own widgets, and only redraw if they should. That should make it much faster.

[HenryHu]

I've figured out that the slowest part in draw_canvas() is rotate_canvas(), and it can be made much faster by... doing it in the most basic way (2-level loop).
I suppose it can be even faster with some optimizations, but it has no performance issue on my keyboard at all now.
see #39