Sunday, November 19th 2017, 8:56pm UTC+1

You are not logged in.

  • Login
  • Register

janulo

Beginner

Date of registration: Oct 17th 2017

Posts: 5

1

Tuesday, October 17th 2017, 10:41am

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
janulo has attached the following images:
  • STemWin1r.jpg
  • STemWin2r.jpg
  • STemWin3r.jpg

SEGGER - Schoenen

Super Moderator

Date of registration: Aug 13th 2015

Posts: 410

2

Wednesday, October 18th 2017, 11:39am

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
SEGGER - Schoenen has attached the following file:
  • WindowOverGIF.zip (5.62 kB - 24 times downloaded - Last download: Nov 16th 2017, 2:17pm)

janulo

Beginner

Date of registration: Oct 17th 2017

Posts: 5

3

Wednesday, October 18th 2017, 3:36pm

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

SEGGER - Schoenen

Super Moderator

Date of registration: Aug 13th 2015

Posts: 410

4

Wednesday, October 18th 2017, 4:16pm

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
SEGGER - Schoenen has attached the following file:

janulo

Beginner

Date of registration: Oct 17th 2017

Posts: 5

5

Thursday, October 19th 2017, 10:57am

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.

SEGGER - Schoenen

Super Moderator

Date of registration: Aug 13th 2015

Posts: 410

6

Thursday, October 19th 2017, 4:13pm

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

janulo

Beginner

Date of registration: Oct 17th 2017

Posts: 5

7

Monday, October 23rd 2017, 9:10am

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

SEGGER - Schoenen

Super Moderator

Date of registration: Aug 13th 2015

Posts: 410

8

Monday, October 23rd 2017, 3:20pm

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

janulo

Beginner

Date of registration: Oct 17th 2017

Posts: 5

9

Monday, October 23rd 2017, 4:39pm

Thanks Sven, it sounds good, I will check it. We have relatively big external flash memory for pictures, so having uncompressed pictures should be feasible.

Jan