kleidos/test/ui/test_screen_painter/ at main · jmrp.io/kleidos

[READ-ONLY] Mirror of https://github.com/jmrplens/kleidos. Kleidos — Hardware BLE password manager for ESP32-S3 (M5StickC Plus2, StickS3, M5Stack Gray, T-Deck, Cardputer) jmrplens.github.io/kleidos/

Fork 0

kleidos / test / ui / test_screen_painter /

at main 1 file

José M. Requena Plens Drive the Stick vault-menu animation through ScreenPainter 3w ago

756c9f5d

test_screen_painter.cpp

Drive the Stick vault-menu animation through ScreenPainter The Stick menu's per-frame animation (drawStickMenuAnimFrame) cleared and recomposed the whole screen every tick — header, list, footer, tab pill — then relied on the single shadow-FB blit for flicker-freedom, so it re-blitted the full 135x240 frame ~8-10 times per scroll/highlight slide even though only the list body moves. Route it through ui::ScreenPainter instead: the header+tab band repaints only when the tab pill is sliding (a tab switch), the list body repaints every frame (clipped to its band, which also masks the sub-row overshoot the header/footer used to mask), and the footer is left untouched in the persistent shadow. A pure scroll now blits just the body band (~40% less per frame) and skips the header/footer re-render. Add a startFull=false ScreenPainter constructor so a short-lived per-frame painter driving already-painted chrome does not force a full repaint; host test covers it. Verified on StickS3 hardware: render is pixel-correct (no uncleared bands) and RENDERSTATS confirms the animation frames dropped below the full-screen blit. First screen migrated onto the central dirty-only mechanism; the menu's status-tick full redraw (battery/BLE) is the next target.

3 weeks ago

Configure Feed

Configure Feed