OK, thanks for the info. Then, assuming there is no overhead, we can do the following calculations:
1. Calculate the number of bits that can be transferred in one tick (~16 ms):
62Hz * 10^6 * (1 / 60FPS) = 1.033.333 bits
2. Calculate the number of bits in a framebuffer:
240px * 280px * 16bpp = 1.075.200
Since the number of bits in the framebuffer exceeds the number of bits that can be transferred on SPI within one tick, achieving 60 FPS is not possible if double framebuffers are implemented in the usual way.
There are ways to work around this, though. You can implement custom code to transfer only the parts of the framebuffer that have been updated/rendered. This can be achieved using different methods with varying levels of complexity. For the simplest implementation, refer to the flushFrameBuffer function in TouchGFXHAL.cpp in the NUCLEO-U575ZI + RVA35HI TBS available in TouchGFX Designer. In this implementation, the minimum and maximum updated lines in the framebuffer are calculated, and only the area in between is transferred. However, this approach will not help if pixels in both the first and last lines of the framebuffer are updated.
You can enhance performance further at the cost of increased complexity by calculating the actual rects of the framebuffer that are updated and transferring only these. However, in any case, you cannot achieve 60 FPS if the entire framebuffer is updated.
The optimal framebuffer strategy depends on the system setup. Since you are using H7, which is a quite powerful MCU, your primary limitation is most likely the bandwidth to the display. Therefore, the most suitable framebuffer strategy might be to continue using partial framebuffer. By using a partial framebuffer, you essentially benefit from the previously mentioned method of transferring only the updated framebuffer blocks. However, the downside of this approach is that it will not perform well with SVGs and some Canvas Widgets.
Best regards,
Johan
