-
-
Notifications
You must be signed in to change notification settings - Fork 938
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
Move analog watch face background into resources #1819
Move analog watch face background into resources #1819
Conversation
Build checks have not completed. Possible reasons for this are:
|
Do you think we could draw the background with lvgl instead? It's just some lines in a circle, right? |
That's probably a better option. It looks like we'd have to use Canvas for that, which is currently disabled in lvgl does have a Line object, but we'd have to create separate instances for each minute (~50 of them), which we probably don't want to do. |
Another option is to implement our own run-length encoding for images (LVGL seems to allow custom image decoders). This would work well for the current background (as it's mostly empty space), but wouldn't work too well for other images. |
That's a wild solution for sure! 😄 Maybe it's worth more to have canvases than a random image if the needed space would be comparable. Also imagine how cool it would look if the background wouldn't be drawn like right now, but instead the lines would appear one after another along the circle in clockwise direction. |
Thanks for your contribution, @jackwilsdon ! So yes, just moving the image to the external resources makes the rendering of the watch face very slow : the SPI bus is limited to 8MHz and is shared between the display and the flash memory. I don't think using RLE is an option here : LVGL needs to be able to access the image in a random fashion to refresh only parts of the frame. With RLE, you would need to read and "uncompress" the whole picture even if only a part of it is needed. Last time I checked, LVGL canvas was not an option either : canvas needs to allocate the memory corresponding to the size of the canvas. In this case, you would need 2402402 = 115200B in RAM memory, which is not possible on the PineTime (it only has 64KB of RAM). But hey! Don't give up! You might be able to find a nice solution, and it would be very beneficial to InfiniTime if you manage to free a few kB in the internal flash memory! |
Maybe you can build a clock from a gauge? |
This decreases the size of the text section from 409,280 bytes to 394,928 bytes (-14,352 bytes). I've made this a draft PR as currently I am having issues with
lv_img_conv
crashing in the Docker container when using an indexed color type (specificallyCF_INDEXED_2_BIT
, which works fine outside of the container). I've opened the PR with theCF_TRUE_COLOR_ALPHA
color type for now, but this results in a huge resource (172,804 bytes).