olikraus
commented
2 years ago Nice question. Let me try to give some technical background:
Monochrome Displays require lesser data to handle and transfer from controller to display. Assuming your above display: A 240x240 monochrome display require 7200 Bytes to handle and maybe store in main memory of the controller. The same 240x240 RGB display would require between 115200 Bytes (16 bit per pixel) and 172800 Bytes (24 bit per pixel).
I think stil pictures can be used on any system, interactive user interfaces require more resources.
I personally say this: Only the ESP32 can store the full RGB data in contronller memory and sould be prefered for RGB displays. On the other side: The library should be able to store the full memory page in RAM. Whether this is done or not for the mentioned Bodmer's lib I can not say, but if the lib directly writes to the display without storing data in RAM, then there will be a lot of flicker visible for interactive menues.
So the question is: Do you need interactive graphics. If yes: A frame buffer in controller memory is required for flicker free display update.
Existing Arduino libraries for monochrome displays (U8g2, Adafruit_GFX) will support the frame buffer in controller approach and nicly support flicker free updates.
Probably all existing Arduino libraries for RGB displays (Adafruit GFX, probably also Bodmer lib above) will write directly to the display to avoid the huge RAM consumption in controller memory. Remember that libraries usually try to support Arduino UNO (2KB RAM): This means, to my knowledge, none of the RGB Arduino libs support flicker free display updates because they avoid using a second frame buffer in RAM of the controller (of course the visual impact can be limited with a fast processor).
So as a conclusion: Monochrome displays and Arduino libs: Always flicker free RGB display and Arduino libs: Probably will always flicker even if RAM would be there. None-Arduino commercial graphics libs might be a solution here
Another visual impact might be the fonts. U8g2 uses hand crafted bitmap fonts, which do look nicely on the display Using a TTF on any of the displays usually requires antialiasing for proper visual experience (which is only possible on RGB displays), but to my knowledge none of the Arduino support antialiasing.
As a consequence, font rendering of Arduino RGB libs usually is not pixel perfect and may look little bit wrong.
However, if you can accept slow response and imperfect fonts, then RGB displays might be fine.
tomzbj
Sorry for opening an issue on this, but as far as I've seen, there is no u8g2 discussion forum/channel.
Which easy-to-use, fast-to-compile, low memory footprint C/C++ library do you recommend for use on small TFT color displays, such as the GMT130-v1.0 240*240 px 1.3" IPS (ST7789 controller) on an ESP8266 (4 MB) or ESP32 running Arduino? We've been experimenting with u8g2 and SH1106 OLED displays, but also would try color displays.
How about Bodmer’s TFT_eSPI?
