slide show implementation

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • 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
  • 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,
  • 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.


    The post was edited 1 time, last by ezio_noventa ().

  • 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,