Hi all --
When we run our color TFT screens etc., of course we make use of graphics libraries...
I use the Adafruit GFX graphics library... I think there is another prominent one also.
Do any of these graphics libraries offer the ability to "flip" between two screen buffers? That is a feature that I have seen in gaming libraries like PyGame. You do your various changes to the screen in the buffer that's not being shown, and then you simply issue a flip command so that the refresh is nice and fast...
have you seen that in any arduino-related graphics libraries?
Think about it. A 240x320 TFT like ILI9341 has got 76800 pixels (153600 bytes of memory).
You can draw all 76800 pixels from an external RAM quite fast e.g. in 50ms.
Do you have external DRAM or SRAM?
But you want to switch "instantly".
This is only possible if you have a smaller screen e.g. a 128x128 panel with a 240x320 controller.
Or you accept less colours.
SSD1963 is the only controller that is sometimes mounted on smaller panels than 800x480.
Most controllers can do 256 colours instead of 65536 colours.
Hmm. When you suggest that I could do a draw of the entire screen in one go quite fast -- what would the method be to do that full screen one-time draw? I'm likely not as advanced a programmer as you.
you see, I was imagining that I would do standard Adafruit GFX commands (placing graphics with the normal calls like circle, line, rectangle, and text)... to a *hidden* page, then do the flip command, and then draw the next round of changes onto the hidden buffer again, flip again, etc. The GFX commands themselves don't render very fast at all, which is what makes me hope for this flipping method.
But it sounds like you suggest a method where I would be able to work with a chunk of memory that's not on the screen, and then spit it all onto the screen in one fast way. Which in a way would be basically similar to this flipping method that I find in libraries.
oh, sorry -- you also asked about external ram. Not too certain what my answer is. in general I work with Uno, Mega, and now feather huzzah ... not certain if that gives you more info about my ram capabilities.
when I did the page-flipping method in the past, it was using a game-writing library ... it worked with a whole large PC screen. it was using python and the library pyGame. That's a larger screen. But I'm guessing that maybe these TFT screens refresh more slowly...
My apologies. The reduced color mode for some controllers is 8-color rather than 256-color.
I have never really looked at it. In fact it still seems to use the same 18-bits of internal memory per pixel as 65k color mode or 262k color mode.
So it does not let you use the spare 10-bits for anything else.
The GFX methods are reasonably fast. But the hardware library still has to talk to your (undisclosed) display.
Uno, Mega are 16MHz and not very powerful.
Feather Huzzah appears to be a ESP8266 board. So you must use a SPI display. Bodmer's TFT_eSPI library is written especially for the ESP8266 / ESP32.
The ESP32 has more RAM than ESP8266. Neither have enough for a "full colour shadow buffer"
It is far easier to answer your questions if you provide information.
But whatever size colour screen you have, it is always best to exercise intelligence i.e. only re-draw minimal areas that have changed.
may I suggest you also take a look at class GFXcanvas1, class GFXcanvas8 and class GFXcanvas16 in Adafruit_GFX. And in Bodmer's TFT_eSPI there is / are Sprite classes for the same, as far as I remember. But I have never used any of these so far.
A canvas could be full screen size, if you have enough RAM.
Both of you, thank you for this! By the way, I forgot to mention that yep, I have been using the ILI9341.
Both of those library recommendations are worth gold, thanks!
And funny that the canvas classes you mention are already sitting on a library that I already use. I guess the little reference sheet that I printed out for Adafruit_GFX was a very basic one, not comprehensive.