Reduced memory and CPU usage by removing animations

[hestiahacker]

This makes the LCD touchscreen noticeable more responsive at the expense of not having the icon fade in and out. Instead of using a fade to indicate the functionality is on, there's a bar above the icons which are currently running.

There's also a small change to the deploy target to make it compatible with systems running either kweb or midori.

This change is a performance improvement no matter what version of Debian or which browser is in use, but it's most important for Debian 11 (bullseye) and Midori (as kweb is no longer maintained and the libraries it needs were dropped in Debian 11).

[hestiahacker]

Feel free to review the changes here, but please hold off on merging this into the default branch until I have time to do some additional testing.

Right now it seems acceptably responsive sometimes, but other times it's like my taps don't register on the screen. I haven't found any pattern to it, and I'm not sure if it's related to switching to Midori or upgrading to Bullseye since those two changes are currently inseparable.

[jaythomas]

@hestiahacker I haven't tested on midori as the target browser in developing this was kweb with all its quirks (also the reason everything is absolute positioned). I'm assuming you're using a Pi Zero based device regarding the performance? I know the interface on the pi zero isn't super responsive but I haven't found it to be unusable with the animation active. I'll check it out this week and see what feedback I can give.

[hestiahacker]

I am testing with both a Pi Zero and a Pi Zero 2 with a number of software configurations.

Debian 11

Up until a few days ago, Debian 11 (bullseye) was the latest stable version. Now there's 12 (bookworm), but I haven't gotten to that yet.

Midori

Bulleye doesn't have the webkit library that kweb needs, hence the switch to Midori (up until last night, more on that later). CPU load and memory usage are high, and the UI is unresponsive at times for 20-30 seconds. After this initial tap is recognized, the responsiveness seems to be okay. It feels like there's something being cached, or swapped out, but I don't have any metrics to confirm this theory.

Kweb

As mentioned above, kweb doesn't work on Bullseye due to using webkit instead of webkit2, but... last night I ported kweb to use webkit2. https://github.com/hestiahacker/kweb/tree/webkit2 Now it compiles on Bullseye just fine, even on the Pi Zero. I still have this UI deployed and it looks fine on both systems using the tiny LCD touchscreen. Everything lines up correctly, it's clear when the heating/cooling/fan are switched on, and the functionality seems to be fine.

Having just done this last night, and seeing as how the problem only shows up after I haven't been interacting with the touchscreen for a while (typically my tests have at least a few hours, sometimes a day or two, in between), I haven't been able to determine if there is any responsiveness issues. Over the next few days I should be able to get a better feel for if there will be any performance issues in this setup.

If this works out well, I plan on abandoning the Midori experiment and sticking with kweb, albeit a different version.

Debian 10

On Debian 10 (buster), I use kweb because it was already set up. Seeing as how Midori seems to be less stripped down, I don't see any incentive to switch away from kweb unless I have to.

The load averages are high on Buster as well, but the responsiveness seems to be okay there (which is strange, but I'll take it).

Debian 8 and 9

These are now end of life and not even getting security patches, however when I was using them they seemed responsive and from what I remember the load averages and memory usage seemed better. I could be misremembering that, because I can't explain why the same versions of the same applications on the same hardware would have different memory usage and CPU load, but it's not terribly relevant now seeing as how they are unmaintained.

[hestiahacker]

Just to close this out, I think this should be merged into the your repo, but not into the default branch.

We're using a browser that is no longer maintained (kweb) because all the other options require more memory and CPU than the Pi Zero has, even with this stripped down theme. This is not idea, but it is the only acceptable solution in terms of performance.

However, it's possible that we may someday switch to a Raspberry Pi Zero 2 (or some future version that isn't out yet) and a browser that is still supported which may only be able to handle this stripped down edition of the UI. So this branch may still come in handy someday, and despite the changes being so small, it actually took me quite a bit of work to get it where it is now!

[jaythomas]

I think the hestiapi hardware should be able to support animations and the software user experience shouldn't regress to support a different browser. However, I think a change in the image used as well as the base pi model used in the hardware are overdue. As you mentioned, the pi zero 2 and pi 3 model b will both handle the animations better (my personal hestiapi uses the pi 3 so I can attest to this).