I'm using a TFT display with integrated ILI9341 controller. The connection between MCU and TFT is 16-bits parallel.
I'm confused about the best strategy to refresh the display when some parts change.
Suppose I have a black background with one image at the center. Every 1 second, a variable is checked and depending on its value the image at the center changes accordingly. The variable is updated in another task.
I can use the background window and call GUI_DrawBitmap() in WM_PAINT message. Every 1 second, I call WM_Invalidate() to force the refresh (maybe in a WM_TIMER message).
This works, but I suspect the GUI library is forced to redraw (i.e., re-write) every pixel of the display, not only the pixels of the image that could change. If the display is big and the image small, this approach wastes a lot of time.
So what is a better approach? I'm thinking to create an IMAGE widget in WM_CREATE and change the image with IMAGE_SetBitmap() directly in WM_TIMER (raised every second) and not in WM_PAINT.
I can't use a data cache, because I don't have so much memory space.
I'm confused about the best strategy to refresh the display when some parts change.
Suppose I have a black background with one image at the center. Every 1 second, a variable is checked and depending on its value the image at the center changes accordingly. The variable is updated in another task.
I can use the background window and call GUI_DrawBitmap() in WM_PAINT message. Every 1 second, I call WM_Invalidate() to force the refresh (maybe in a WM_TIMER message).
This works, but I suspect the GUI library is forced to redraw (i.e., re-write) every pixel of the display, not only the pixels of the image that could change. If the display is big and the image small, this approach wastes a lot of time.
So what is a better approach? I'm thinking to create an IMAGE widget in WM_CREATE and change the image with IMAGE_SetBitmap() directly in WM_TIMER (raised every second) and not in WM_PAINT.
I can't use a data cache, because I don't have so much memory space.