Monday, February 26th 2018, 2:02am UTC+1

You are not logged in.

  • Login
  • Register

Dear visitor, welcome to SEGGER Forum. If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

Date of registration: Jul 7th 2014

Posts: 33


Tuesday, October 7th 2014, 3:41pm

slide show implementation

Dear all,

we are trying to implement a simple slide show application where four pictures have to be displayed in a cyclic manner.

We use a window with an IMAGE widget and we set the picture using IMAGE_SetDTA() function.

In the main() function there is the following while(1) loop

Msg.MsgId = WM_USER;
Msg.Data.v = slide_show_counter%4;
Msg.Data.v = slide_show_counter%4;

so each 2 seconds the main() application sends a message to the slideshow window using a WM_USER type of message
and in the callback function of hWin the WM_USER message reception is managed in this way:

switch (pMsg->MsgId) {


case WM_USER:
picture_index = pMsg->Data.v;
hItem = WM_GetDialogItem(pMsg->hWin, ID_IMAGE_CALL_ANIM_0);
pData = _GetImageById(picture_id_array[picture_index], &FileSize);
IMAGE_SetDTA(hItem, pData, FileSize);

picture_id_array stores the ids of the four images we need to display in a cyclic manner.

When it is time to update the window the emWin window manager changes the picture accordingly to the new setting.

The mechanism seems to work, there is however a bad side effect: something in the lcd module refresh procedure somehow
interferes with the picture display such that you see a very annoying flash on the screen, as if the emWin library were
not able to perform the needed operations within the lcd refresh cycle and actually what you sometimes see on the screen
is a stripe with the background color.

Can you suggest an idea in order to syncronize the STM32F4 lcd controller and the emWin window manager engine?

Or alternatively can you suggest a different approach in order to implement the slide show?

One more information: the smaller are the pictures and the less is the side effect visible, that is why we think it is
some task in the emWin library that takes too much time to be accomplished
Best regards

Date of registration: May 26th 2009

Posts: 1,022


Thursday, October 9th 2014, 9:22am

Hello Ezio,

In your application the data is loaded from external memory. This might likely be the time-consuming part. In order to avoid flickering in such a case MultiBuffering might be an option for you. Do you already use automatic MultiBuffering with the Window Manager? For details please refer to the chapter "Multiple Buffering" in the emWin user manual.

Best regards,

Date of registration: Jul 7th 2014

Posts: 33


Friday, October 10th 2014, 10:52am

Dear Adrian,

I did some tests using WM_MULTIBUF_Enable and actually the issue is solved.
The problem is that I should avoid the allocation of two frame buffers (final design of the board should be without external sdram component) and, it seems to me, multibuffering works if and only if a second frame buffer can be allocated. Am I correct?

I see that in the LCD_X_DisplayDriver function there is a LCD_X_SHOWBUFFER case, but, my question, is it used only with multibuffering?

Because, may be, I could somehow delay the frame buffer update.


This post has been edited 1 times, last edit by "ezio_noventa" (Oct 10th 2014, 10:57am)

Date of registration: May 26th 2009

Posts: 1,022


Friday, October 10th 2014, 3:28pm

Hello Ezio,

Yes, Multiple Buffering requires at least 2 frame buffers, but can also be performed with 3 frame buffers. 2 frame buffers help avoid flickering. 3 frame buffers help avoid tearing effects as well. Please refer to the emWin user manual in order to find out which display driver callback messages are sent by which driver.

Best regards,