Consider setting `buffer_size` in `display` constructor

[tomsci]

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]

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]

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]

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]

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