-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Consider setting buffer_size
in display
constructor
#20
Comments
My personal opinion is we should allocate a buffer the size of the internal display buffer, which is bigger than the screen size. We want to be able to load images the size of the internal buffer for scrolling graphics. |
Normally I'd agree but I can't see any way to use the st7789 APIs to achieve offscreen drawing followed by scrolling it onscreen. I haven't found a way to use Happy to be proved wrong though, I'd definitely like to do some fancier scrolling effects! |
This is a limitation of the library, not the hardware. You're allowed to write to any part of the display buffer, in any direction (!) with any stride length you want, and you can set the display window to anything you like, and also change the display window between frames without changing the buffer contents. |
To clarify further, you can't do these fancy things with the builtin scrolling functionality, which works exactly as you describe, so doing those fancy things requires animating the display window manually |
Raising this so I don't forget about it.
Right now we don't set
buffer_size
in theST7789()
constructor. This means every call tobitmap()
andtext()
will malloc a temporary buffer. For a fullscreen image this means a 64K malloc every time. I managed to somehow hit an OOM error as a result of this (although I've no idea how I could've leaked or fragmented 8MB!). Maybe we should just take the 64KB penalty and keep the buffer around all the time, to reduce fragmentation? (the buffer_size has to be big enough for the largest image we're going to load, so setting a limit of no images larger than the screen size seems reasonable for now)@MatthewWilkes what do you think?
The text was updated successfully, but these errors were encountered: