DirectAccess for better bitmap performance

Question

Hello,

We're working on a system with a fairly small number of bitmaps on screens (Some are 'full screen', around 480x160 pixels, others are small.)

At the moment we're using 'compressed' as we're still developing an external flash driver for our target hardware. We've noticed that the graphics performance shows a lot of tearing and flickering during screen changes.

We ran the app on a discovery board and used 'DirectAccess' for bitmaps and found the graphics performance far better, with no tearing or corruption.

Is this because DIrectAccess uses DMA to transfer bitmap data from flash?

Is DirectAccess the best mechanism to use for performance? If we increase SDRAM and use compressed can we get better performance?

(The MCU is a STM32F469 using RGB888)

Answer 1

Hello,

I think your question contains two different aspects:

1.) Compressed vs. DirectAccess - In case of STM32 and in case you have SDRAM, the usage of Compressed results in better performance. DirectAccess is recommended for targets without SDRAM or only with very small RAM.

2.) Tearing and Flickering - I assume you do not have a MIPI-DSI display as it is used on the STM32F469 Discovery board. If it is connected via RGB parallel interface, you can avoid the tearing and flickering by using double-buffering. Have you set EW_USE_DOUBLE_BUFFER to 1?

Best regards,

Manfred

Comments

Hi Manfred,

Thanks for your reply. We're currently increasing the SDRAM size.

We are using MIPI-DSI (With a different display to the DIsco board) with EW_USE_DOUBLE_BUFFER set to 1.

---

Hello,

is the MIPI-DSI display driven in command mode (as it is the case on Disco board) or in video mode? In case of video mode you have to take care to do the exchange of front-buffer and back-buffer on V-sync. Otherwise tearing may occur.

Best regard,

Manfred

---

Dear Manfred,

Thanks  for your prompt response. We're using command mode, but I'm not responsible for this aspect of the system so I do not know if the V-sync has been implemented in this way. (I know the implementation was hampered by poor specifications.)

I shall start investigations in this area.

Regards

Harbottle

---

Hello again,

After investigations, we found that turning off double buffering got rid of most of the problems. We are using DSI in command mode with an external pin connected to the TE, so do not believe we need double buffering as we are using the TES.

However, we still see some tearing - they are triangular artefacts in the middle/LSH of the LCD and appear briefly when changing graphics on the screen - always in the same position.

Any ideas?

---

Hello,

there are not really much good ideas that could help... Maybe one thing: You mentioned that you see triangular artifacts. This could happen in case that the orientation how you update the graphics memory (GRAM) of the display is different from the orientation how the display controller reads the GRAM. The fact that these triangular artifacts appears on the same location indicates that the V-sync seems to work - but maybe there are two different orientations (row wise vs. column wise).

But just an idea - without having seen the issue.

Best regards,

Manfred.

---

That's interesting, as the Framebuffer is 480x320, but the display controller's internal GRAM is 320x480 (i.e. 480 scanlines) - so we are in fact rendering in the frame buffer in a different orientation (The display is fitted in 'landscape'.)