Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lvgl: get rgb332 default #189

Closed
bwhitman opened this issue Mar 12, 2024 · 3 comments
Closed

lvgl: get rgb332 default #189

bwhitman opened this issue Mar 12, 2024 · 3 comments

Comments

@bwhitman
Copy link
Collaborator

from #179 , will carve this out separately:

investigate / hack up LVGL 9 to support rgb332 natively so save on RAM and CPU for Tulip. It apparently was supported in previous LVGL versions and looks to be possible again using an 8-bit palette hardcoded to rgb332. Not a blocker for release, speeds are OK, but i hate the idea of Tulip wasting cycles doing RGB565-332 conversions when it doesn't need to.

@bwhitman
Copy link
Collaborator Author

It looks like RGB332 is deprecated from LVGL9. I can see if lv_bindings_micropython has a lvgl8 version, where it still exists. It does feel like v9 is still very buggy and undocumented so this may help for other reasons.

lvgl/lvgl@5e32678

@bwhitman
Copy link
Collaborator Author

bwhitman commented Apr 3, 2024

The 18 month old lv_bindings for lvgl8 is not compatible with our recent micropython, so we're 'stuck' with lvgl9 for now.
I found a PR for supporting L8 color, which I believe is greyscale 0-255 for eink or grey displays. This PR does work great on Tulip -- it cuts loading (e.g.) Juno6 on startup from 780ms to 420ms and switching between REPL and Juno from 540ms to 150ms. This makes a big difference in usability.

However, two issues:

(1) We'll need to write our own color blending and conversion code, probably just doing the work they did for L8 to get RGB332 back again. As of now, it looks like a early-90s swatch (see below) as it's mapping greyscale to RGB332. I don't yet know if this is a couple of hours or a long slog to get to. I'll try it out

(2) It is noticeably faster to replace the PARTIAL mode with an intermediate buffer with DIRECT, writing right to the BG FB. But, Tulip historians recall, our FB is actually 2*H_RES x V_RES+150 for scrolling and off-screen drawing. Very few people have used these features since Tulip has come out so I'd be interested in removing them (maybe keeping a second BG FB around for offline drawing, but removing hardware scroll) We also may be able to get away with having "offscreen" LVGL components as well, but i fear it'll get in the way of the very useful scroll they provide.

IMG_3549

@bwhitman
Copy link
Collaborator Author

bwhitman commented Apr 4, 2024

This is all done. there's some small blending quirks, i'll make a new issue for them

@bwhitman bwhitman closed this as completed Apr 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant