Memory device with GIF or PNG drawing and text overlay - flicker

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

  • Memory device with GIF or PNG drawing and text overlay - flicker

    Hi everyone,

    I would like to reduce the flickering effect when changing a background image showing a scale (190x190) and a text in front of that (as overlay).
    Presently I use IMAGE_SetGIF (or SetPNG) for drawing that area of a dialog window. Directly after that, a text will be updated in the middle (SetText).
    The drawing effect (update) is visible when using the NOTIFICATION_RELEASED message after touch event. The update of the area and the text are visible as two paint events. (The LCD driver is fast > 5MPixel/s). So this should be an error by define or using the wrong method.
    Using the memory device for WIN32 GUI works fine, of course (using WM_SetCreateFlags(WM_CF_MEMDEV) for all dialog windows), as I have enough RAM in Windows.
    But that does not work in my application, since the dialog size is 320x240 (fullscreen) and the drawing of the full window stops in the middle due to lack of RAM. I can reproduce that by changing the size of the windows simulation the same I have for the 429 discovery.
    So, the question is, if I have to use a different function for painting, or creating a memory device for the required area only (190x190) or use AutoDev
    Is the SetGIF responsible for that? Should I use the native bitmap functions in combination with memory devices? I have to paint the new GIF, afterwards change the text and then the display should be updated.
    Or is it possible to use the MEMDEV-flags in the defined dialog array (IMAGE_CreateIndirect) instead?
    I do not use the WM_PAINT for changing or updating the window area. And I did not test yet to define that area as a child window.

    The sample MEMDEV_Banding works fine (just to be sure that no other issue is affecting that). Disabling the MEMDEV-function here shows the same flicker I can see in my application (single paint updates). So, I think MEMDEV should be the way. But the available RAM is limited...

    Any suggestions?

    Best regards,
    HaJo

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

  • Hello Adrian,
    so I should implement a send message (WM_SendMessageNoPara(hWIn,WM_PAINT) in the WM_NOTIFICATION_RELEASED-case instead of redrawing it here diectly? Is that correct? I have to trigger WM_PAINT to draw the new GIF and text here.
    What about the memory device issue?
    Best regards,
    HaJo
  • Hello HaJo,

    I would recommend to never force a drawing operation. The main part in the application should be a regular GUI_Delay() or GUI_Exec(). As an event happens which causes a window to change its appearance, the window should be invalidated. Invalid windows are redrawn the next time the Window Manager is executed.

    Details can be found in the emWin user manual.

    Best regards,
    Adrian
  • Hello Adrian,

    I checked some samples, but I think, I did not get the invalidation idea.
    Sample WM_Redraw:
    Invalidate forces the window to be redrawn (by GUI_Exec or in GUI_Delay), right? But I like the changes to be drawn in one screen update.

    In my App hwin= GUI_CreateDialogBox... is followed by while(1) GUI_Delay(1000)

    The event is the touch event. As you said, I should not do any drawings then, otherwise they will be visible as two paint actions with flicker.

    Where do I have to put the new SetText and new Image_SetGIF to avoid two updates?
    What is the main problem in my app? The wrong position of the required display changes or not using a memory device for this area?

    I could use a flag triggered by the msg ...RELEASE to (re)paint the new GIF and TEXT in the WM_PAINT-case of the window. Is that what you mean?
    Where do I have to put the "invalidate"?

    Best regards,
    HaJo
  • Hello Adrian,

    I will now move all paint actions to WM_PAINT. However, the GUIBuilder puts all the Image_Set... into the INIT case.
    But how do I trigger the WM_PAINT again, without using the SendMessage after the RELEASED-event for changing the pictures?
    WM_invalidate(..) inside ..RELEASED? Or better use InvalidateRect for that smaller picture area?

    GUI_PNG_Draw and GIF does not work in the ..INIT case but in WM_PAINT. So that is fine.
    Should I use the GUI_PNG_Draw instead of Image_SetPNG to change the picture? What is the difference inside?

    Can you confirm, that using IMAGE_CF_MEMDEV in IMAGE_CreateIndirect for the image itself instead of the whole window should also reduce flicker when changing that image area (in the WM_PAINT)? On top, in the middle of that picture is text with transparent background...(Text_CreateIndirect).

    Best regards,
    HaJo
  • O.K.

    I kicked out the PNG-function due to lack of memory in combination with memdev.
    Now I am able to use memory device for the complete window. No flicker anymore.
    Most icons used have less than 256 colors with transparency, so no problem. All other pictures with more colors will be implemented as C-file (compressed) in flash.
    External files from SD will be DTA (True color with ALPHA). This all works fine. PNG-functions need too much memory.

    As you said, all these drawing routines will now be triggered in WM_PAINT.
    But after activating memdev with WM_SetCreateFlags(WM_CF_MEMDEV) some pictures are not drawn. Text will always be drawn. Do I have to set other flags to update the background? Creating child windows and deleting them updates the background.
    I will try WM_SetDesktopColor() tomorrow.


    Best regards,
    HaJo