Skip to content
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

Open
tomsci opened this issue Apr 23, 2022 · 4 comments
Open

Consider setting buffer_size in display constructor #20

tomsci opened this issue Apr 23, 2022 · 4 comments

Comments

@tomsci
Copy link
Contributor

tomsci commented Apr 23, 2022

Raising this so I don't forget about it.

Right now we don't set buffer_size in the ST7789() constructor. This means every call to bitmap() and text() 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?

@kliment
Copy link
Contributor

kliment commented Apr 23, 2022

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.

@tomsci
Copy link
Contributor Author

tomsci commented Apr 23, 2022

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 vscsad() to permit anything other than "rolling scroll", where you're still displaying exactly the same 135x240 pixels, just wrapped around the screen with a variable offset (which is what the emflogo app does). The buffer that buffer_size controls is only used as an intermediate and I don't think you can use it as an offscreen bitmap.

Happy to be proved wrong though, I'd definitely like to do some fancier scrolling effects!

@kliment
Copy link
Contributor

kliment commented Apr 23, 2022

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.

@kliment
Copy link
Contributor

kliment commented Apr 23, 2022

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

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants