Troubleshooting emWin Animation Performance

jhgorse · Feb 2nd 2021, 5:56am

Greetings,

I have a custom widget I am making that expands a row when it is selected, then fades in the window for editing. The expansion animation and the fade in work fine. The fade out does not, nor does the returning animation unless I immediately initiation them upon their initial completion. The fade out and following animation are jerky.

Rather than solving just this particular problem, I would like to learn how to find where emWin is spending it's time.

I have plenty of memory and the platform is the simulation.

Cheers,
Joe

SEGGER - Florian · Feb 2nd 2021, 9:39am

Hi,

are you using the routines GUI_MEMDEV_FadeInWindow()/GUI_MEMDEV_FadeOutWindow()? These routines are blocking, that means emWin cannot continue with an animation while a FadeIn/Out routine is running. Therefore, they are not recommended to be used with animations.

Can you send me an example that demonstrates your issue?

Best regards,
Florian

jhgorse · Feb 2nd 2021, 2:29pm

Florian,

Yes, those are the routines. The animations occur before and after the fade in/out, sequentially. I need to strip the code to make an example.

Cheers,
Joe

jhgorse · Feb 3rd 2021, 6:00am

Florian,

I removed the GUI_Lib/GUI.lib and GUISim_GUI_USE_ABGR.zip to fit the 1 MB requirement. You will need to re-add GUI_Lib/GUI.lib.

Steps to reproduce

Compile and run the simulation.
Press Down arrow key to focus the first row.
Press Enter to select the first row.
Observe the animation, then fade in sequence.
Press Right arrow key to focus the right button.
Press Enter to exit the edit mode.
Observe a lack of Fade Out, then the deletion of the window, then the animation performs as expected.

Notes

emWinView appears to show the Fade Out properly.
emWinSPY shows all Windows as not having MDev enabled, which appears to be incorrect.
Not pausing to wait for user input for the transition from Fade In to Fade Out shows the Fade Out as expected.
I had also tried calling GUI_MEMDEV_FadeOutWindow() from the _CLICKED notification msg per your example on the forums but had no luck.

Cheers,
Joe

SEGGER - Florian · Feb 4th 2021, 12:18pm

Hi,

I was able to reproduce the steps. Apart from the glitching fade out, the animation looks pretty good!

As I mentioned, the FadeIn/FadeOut routines are blocking, that means you cannot execute an animation simultaneously to fading out the button with these routines.

Instead, you should fade out the button with an animation. To fade the button out by yourself, you have to draw it manually (set a custom callback). The animation should "animate" a variable for the alpha value from 255 to 0 (0xFF = opaque, 0x00 = transparent). In the button callback, you should then use the alpha value to draw the fading button.

Transparency has to be enabled with GUI_EnableAlpha() when drawing in WM_PAINT. It is very important, that transparency is disabled with GUI_EnableAlpha(0) when all operations are done. For example:

C Source Code

Color = (Alpha << 24) | ColorRGB;
GUI_EnableAlpha(1);
GUI_SetColor(Color);
//
// Draw using semi-transparent color...
//
GUI_EnableAlpha(0);

Best regards,
Florian

jhgorse · Feb 6th 2021, 10:11pm

Florian,

Thank you for the compliment. =)

I had thought about using animation to blend alpha and blur as well, for fun.

The requirement is to blend. Sequentially (blocking mode) is sufficient, though in parallel may be acceptable as well.

Because I am stubborn and curious, how can we dig deeper into emWin to see where the glitching comes in? =)

I will add the alpha blend to the animation as a test.

Cheers,
Joe

jhgorse · Feb 6th 2021, 10:53pm

Florian,

I started implementing this alpha animation and realized there is no way I know of to generically apply alpha mask to a window widget except via GUI_MEMDEV_FadeInWindow and GUI_MEMDEV_FadeOutWindow.

A BUTTON or BOX may have alpha to their background colors. So the notion is to override WM_PAINT messages for those specific callbacks. Does this require manually drawing the widgets and their data with GUI_Draw*() calls?

This does not seem like a scalable approach.

I have attached an example version named MainMenu - No Pause - Pass.zip which demonstrates GUI_MEMDEV_FadeOutWindow working as expected when there is no user interaction to fade out. In other words, it fades in then out immediately in succession. The steps to reproduce are roughly the same as above, but with one less unselect step.

Cheers,
Joe

SEGGER - Florian · Feb 9th 2021, 10:48am

Hi,

jhgorse wrote:

Does this require manually drawing the widgets and their data with GUI_Draw*() calls?

Yes, pretty much... I know that this can become tedious. An easier way that could work would be to overwrite WM_PAINT, set the alpha value and call the default callback. But note that this would require a lot of performance.

C Source Code

case WM_PAINT:
GUI_SetAlpha(Alpha);
BUTTON_Callback(pMsg);
GUI_SetAlpha(0xFF);
break;

By the way, you can only set a custom callback to emWin widgets, not AppWizard objects.

A better way would be to copy the window to be blended into a memory device and hide that window. Then you could continuously draw the memory device with a new alpha value.

Best regards,
Florian

C Source Code

C Source Code

Share