So the results are here and they explain a lot.
The tests are 3.
A is a button pressed that controls directly a GPIO item of the RasPi. No rules are triggered.
B is a small button pressed that controls an OH variable shown in very small font. A few rules are triggered.
C is a large button pressed that controls an OH variable shown in large font. No rules are triggered.
Here are the scenarios used for the above 3 tests. The numbers below each scenario is the response delay in seconds measured by hand and a runner’s stopwatch using a stylus to press accurately the LCD.
-
Load the paper UI in Chromium on the LCD
<1sec
1.3
1.6 -
Stock HABPanel with HestiaPi’s UI loaded
<1sec
2
<2 -
Optimised HABPanel from csowada
1sec (I guess the difference is negligible and hard to see by hand)
1.6
1.6 -
Same as above but the HABPanel got most of its items removed to see if many items matter
1sec
NA (the button used here is removed)
1.6 -
Running Chromium, showing HABPanel hosted on a remote (but local) RasPi Zero
<1sec
1.6
1.3
So my conclusions are:
- @csowada version does help
- Rendering area on the screen affects the responsiveness
- Running both OH2 and Chromium on the same RasPi Zero is too much
- Amount of items (within limits) does not affect the responsiveness
- Amount of rules (within limits) does not affect the responsiveness
- Smooth operation is not possible (yet)
- Memory is probably not the bottleneck but the actual (peak) CPU load
I hope I help others within and outside the OH community.
Thank you all !