Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

u8g2 Equivalent for full color TFT displays such as GMT130-v1.0 ST7789? #1785

Closed
Wookbert opened this issue Feb 16, 2022 · 1 comment
Closed

Comments

@Wookbert
Copy link

Wookbert commented Feb 16, 2022

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?
imageimage

@olikraus
Copy link
Owner

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.

@olikraus olikraus closed this as completed Mar 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants