Posted on January 16, 2015 at 22:30H/W: STM324x9I-EVAL
S/W C:\STM32Cube_FW_F4_V1.3.0\Projects\STM324x9I_EVAL\Examples\DCMI\DCMI_CaptureMode (No RTOS - just a polling loop.)
I have modified this to include STemWin and touch and display camera data in a window within STemWin. The problem I would like to solve is tearing. The camera runs about 14 fps and the screen updates at about 60 fps so each time it updates, it gets a little more of the next camera frame.
To fix this I have implemented double buffering using the following strategy:
0) Remove the operation that normally copies the data from the camera buffer to the LCD frame buffer from BSP_CAMERA_LineEventCallback()
1) Set a flag to indicate 'frame ready' in BSP_CAMERA_FrameEventCallback()
2) Poll this flag in the main loop and when set:
a) call GUI_MULTIBUF_Begin() to notify STemWin of the desir4e to write the back buffer.
b) copy the data from the incoming camera buffer to the LCD frame buffer (Indexing the buffer by using layer_prop[0].buffer_index from LCDConf_stm324x9i_eval_MB1046.c which has been made public)
c) calling GUI_MULTIBUF_End() to signal STemWin that the buffer is ready to bring forward.
d) calling GUI_Exec1() to get the new display buffer brought forward.
This generally works well and has solved the tearing problem but with one or two artefacts.
The first line of the screen looks like the first line of the next camera frame. By this, I mean that if I move something back and forth across the screen, the image in the first line leads the lines below it. The second and perhaps related artifact is that the second line of the display looks like the image background prior to camera image being displayed. (The code paints the image over a similarly sized IMAGE widget to make any image placement errors obvious.)
I've tried a few different things to see if this could be fixed, but with no positive results.
Some lyin' stinklin' developer thought that no one would notice 238 lines vs. 240 lines and thought he could work around this problem by starting the display on the third line. Surprisingly that did not fix the problem.
Any suggestions for why the artefacts might be there or better solutions to this problem are very welcome and highly appreciated!
Thanks!
#double-buffer-tearing
