Shaker and input calibration options in klipperscreen and guppyscreen crash due to memory constraints

[consp]

Since this is a wider issue a new issue.

What happens:

1. start input shaper from klipperscreen or guppyscreen
2. x-asis runs fine and it stops after the x axis calculations eat too much memory resulting in a timeout and a firmware restart being required

Known stuff:

• numpy starts eating the memory after the X asis calibration
• The second run will most likely work, probably due to some GC magic or swapping out of pages
• Importing numpy ahead of start sometimes allows it to succeed
• The extra free memory in the lite variant allows it to succeed most of the time but it sometimes still stalls
• Memory usage is converted to swap but due to swap being slow it is not fast enough to cope with the increased demand

[xblax]

It's related to this issue https://github.com/xblax/flashforge_ad5m_klipper_mod/issues/64, correct?

For me it was mostly working ok, but I think I only did it with the lite variant from Mainsail so far. Luckily, that calibration must only be done once or maybe every few months. If it's not working on the first attempt it can be just be repeated.

For the UIs it's maybe a bit more annoying if these don't handle the failure correctly.

For KlipperScreen we can save a bit more RAM by replacing the the SVGs with PNGs, which I wanted to look into but didn't mange to do for the latest release.

[consp]

For KlipperScreen we can save a bit more RAM by replacing the the SVGs with PNGs, which I wanted to look into but didn't mange to do for the latest release.

I did it but didn't push it yet as it requires a bit more testing, saves a bit of memory but not a lot. If I get it working properly I'll push it to the feature branch. See https://github.com/KlipperScreen/KlipperScreen/commit/882c4488511782efe34296865f694f641332d154

It's related to #64 might be the same but also might be multiple issues together and the GUIs should report an error instead of nothing.

[xblax]

Ah, did you have to patch KlipperSreen to support PNGs? Because according to the docs it should be support for themes: https://klipperscreen.readthedocs.io/en/latest/Theming/

I think when I was using libtiny-svg with the libtinysvg-pixbuf it was accepting the pngs, but not with librsvg. I also think I rendered the pngs quite a bit smaller, 2x the viewport size.

[consp]

It selects svg before png and some svg's are hardcoded (I think two), so I disabled that to be sure. Rendering looks ok:

$ smem
1426 root     /root/printer_software/Klip     4560    29800    31548    35216

$ cat /proc/1426/maps | grep -E '(svg|png)'
b5a60000-b5a97000 r-xp 00000000 b3:07 261718     /usr/lib/libpng16.so.16.39.0
b5a97000-b5aa6000 ---p 00037000 b3:07 261718     /usr/lib/libpng16.so.16.39.0
b5aa6000-b5aa7000 r--p 00036000 b3:07 261718     /usr/lib/libpng16.so.16.39.0
b5aa7000-b5aa8000 rw-p 00037000 b3:07 261718     /usr/lib/libpng16.so.16.39.0

Pushed to feature branch (updated submodule + removal of svg libs)

[MACCAMENZIES]

Had this output when trying the input shaping with guppy screen.

[consp]

Had this output when trying the input shaping with guppy screen.

Ah, I guess imports. That might be due to the printer.cfg having been changed. Need to figure out a proper way of handeling that, maybe putting the imports somewhere else. @xblax any idea if that would work. Thanks for the report.