-
Notifications
You must be signed in to change notification settings - Fork 28
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
Comments
It looks like RGB332 is deprecated from LVGL9. I can see if |
The 18 month old lv_bindings for lvgl8 is not compatible with our recent micropython, so we're 'stuck' with lvgl9 for now. 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 |
This is all done. there's some small blending quirks, i'll make a new issue for them |
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.
The text was updated successfully, but these errors were encountered: