GUI_GIF_Draw fails drawing on background window if another window is visible over it.

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

  • GUI_GIF_Draw fails drawing on background window if another window is visible over it.

    Dear all,

    I'm successfully using STemWin library on our ST32L4 processor. Thanks for such useful library!

    Currently I have problem with drawing gif on background window using Window Manager. We don't use callback functions currently, but we may if this is the problem.
    The goal is to show current time in right bottom corner (in separate window) while drawing GIF images under this window.
    • If no windows are displayed in front of background window, GUI_GIF_Draw is successful.
    • If some window is visible in front of background window, GUI_GIF_Draw fails with return code 1.

    Please take a look on attached pictures:
    1. background window with some text, and in front of it is Time Window, cleared with green color for better visibility of this window
    2. background window is selected and cleared with blue color. Time Window stays without change - this is OK
    3. picture is displayed using GUI_GIF_Draw, with return code 1. It looks like drawing stops exactly when it hits the Time Window.

    Thank you in advance for any suggestions.

    Jan
    Images
    • STemWin1r.jpg

      67.49 kB, 1,024×767, viewed 504 times
    • STemWin2r.jpg

      118.19 kB, 1,024×768, viewed 451 times
    • STemWin3r.jpg

      81.2 kB, 1,024×818, viewed 458 times
  • Hi,

    Not sure how you manage the drawing, but I recommend to use the callback mechanism of the Window Manager.

    It seems like the background window doesn't 'know' how to redraw itself, so the best would be do set a callback function for the background window managing displaying the text and also the GIF.

    Same for the time window, of course managing its content.

    Attached is an example on how this can be done. The example shows some text for 2 seconds and switches then to draw a GIF image. Another window, which is a child window of the background window (WM_HBKWIN), is always present.

    Regards
    Sven
    Files
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi Sven,

    thanks for quick reply.

    Using callback function and drawing GUI_GIF_Draw (or in my case GUI_GIF_DrawSub to support animations) on WM_PAINT event helped - thanks for nice example.

    I've noticed that to draw one (sub)picture, WM_PAINT event is called 4 times because of early clipping functionality (TimeWindow creates 4 areas around it). When I tried late clipping mode (using WM_SetCreateFlags(WM_CF_LATE_CLIP) before calling GUI_Init() so even desktop window has late clipping enabled), I got the same problem - GUI_GIF_Draw returns 1. So it looks that GIF can be drawn only with early clipping functionality - in this case everything works fine. Please correct me if I'm wrong.

    Regards
    Jan
  • Hi,

    I have also tried it with an animated GIF and WM_CF_LATE_CLIP, but it works without any issues.

    Please check the application attached. It is the same as before, but with an animated GIF using GUI_GIF_DrawSub().

    Regards
    Sven
    Files
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi Sven,

    Thanks for another example :thumbup:


    It's strange, but as soon as I enable WM_CF_LATE_CLIP, GUI_GIF_DrawSub fails when it "colides" with the TimeWindow.
    So probably there is something different in our project (it's quite big with multiple threads), what causes this. Good thing is that early clipping mode works well for us.

    One thing came into my mind, I'm using two threads to access GUI, so I'm linking OS version of library (with all needed OS related function defined, including GUITASK_SetMaxTask(2) inside GUI_X_Config(), right before GUI_ALLOC_AssignMemory(), provided memory size is 30x1024 Bytes). But even if I tried no OS version, GUI_GIF_DrawSub fails the same way, if WM_CF_LATE_CLIP is selected.
  • Hi,

    If it is possible you might try to increase the memory allocated for emWin.

    30K bytes is not that much and for decompression of GIF images a minimum of 16k more than (50% fo the available memory) is required. Maybe there is not enough memory available at some point and the decompression fails, causes GUI_GIF_Draw() to return with 1.

    Are you using memory devices, e.g. with WM_SetCreateFlags(WM_CF_MEMDEV)?

    Regards
    Sven
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi Sven,

    no, I'm not using memory devices.
    I'm afraid that 30KB is maximum available memory we can provide for emWin. I will try to test it on some demo project with bigger memory provided to emWin just to know, but this will be not applicable for current project.
    I will come back with results. Besides this, we can close this issue for now, early clipping is fine for us.
    Thank for your help - ensuring me that using callback mechanism is the right way helped a lot.

    Regards
    Jan
  • Hi,

    Depending on what are the requirements you might try other solutions without GIF images. For example the .dta files. Those are emWin specific bitmaps which are the same as the c-files but in a binary format. These files require no decompression and can be drawn with less RAM requirements (at least one line of bitmap data).

    Please refer to chapter 8.1.5 'Drawing streamed bitmaps' of the emWin user manual. Especially the API description for the '...Ex'-Version of GUI_DrawStreamedBitmap().

    Regards
    Sven
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.