Thursday, June 29th 2017, 9:12am UTC+2

You are not logged in.

  • Login
  • Register

inojosh

Beginner

Date of registration: Jun 1st 2017

Posts: 5

1

Friday, June 9th 2017, 12:10am

Swipelist blocks while decelerating

The swipelist widget appears to block while animating its deceleration after releasing touch.
If you continuously move your finger up and down on the swipelist it does properly move accordingly while also allowing other widgets to draw.
However, if you swipe up/down then release touch, the automatic deceleration blocks other widgets from drawing until the decelerating is done.
I would consider this a bug - the animation for deceleration should not block execution.

Furthermore, this blocking happens even if you are at the end of the list and swipe - execution is blocked even though the swipelist doesn't have to redraw (because you are at the end of the list and there is no more to see).

Thoughts on this? Any way to work around it, or perhaps some other way to draw a swipeable list that doesn't block?

SEGGER - Schoenen

Super Moderator

Date of registration: Aug 13th 2015

Posts: 309

2

Friday, June 9th 2017, 8:17am

Hi,

Which version of emWin are you using (found in GUI_Version.h)?
Do you have a code sample, which allows me to reproduce the behavior?

Regards,
Sven

inojosh

Beginner

Date of registration: Jun 1st 2017

Posts: 5

3

Friday, June 9th 2017, 6:27pm

It is V5.32

It is easy to replicate, just create a swipelist that doesn't cover the whole screen + a dialog with widgets. For widgets, PROGBAR updated with random values is a good way to see the effects of the swipelist.
I've attached a simple demonstration as a text file (.c is not allowed, the forum's inline code blocks ignore carriage returns).
inojosh has attached the following file:
  • swipelist.txt (6.56 kB - 22 times downloaded - Last download: Yesterday, 10:11pm)

This post has been edited 2 times, last edit by "inojosh" (Jun 9th 2017, 6:46pm)


SEGGER - Schoenen

Super Moderator

Date of registration: Aug 13th 2015

Posts: 309

4

Friday, June 16th 2017, 4:41pm

Hi,

I checked your code, but on my end it is working fine. The progressbars are getting updated while the SWIPELIST is decelerating.

Regards,
Sven

inojosh

Beginner

Date of registration: Jun 1st 2017

Posts: 5

5

Friday, June 16th 2017, 6:08pm

For me, it does not work when running on hardware.
I tried it on STM32F746G-DISCO and STM32F769I-DISCO, with and without FreeRTOS.
Here is a short video demonstrating the blocking action. Notice that it blocks even though the swipelist has reached the end.


IN SUMMARY:


Does not block when:
  • you hold your finger on the swipelist and move up and down
  • you call WM_MOTION_SetDefaultPeriod(0) first

Does block when:
  • you swipe and release, allowing the list to decelerate
  • you swipe and release while swipelist has already reached the end

SEGGER - Schoenen

Super Moderator

Date of registration: Aug 13th 2015

Posts: 309

6

Tuesday, June 20th 2017, 4:37pm

Hi,

Which version of emWin are you using?

This information can be found in GUI_Version.h.

Regards,
Sven

inojosh

Beginner

Date of registration: Jun 1st 2017

Posts: 5

7

Tuesday, June 20th 2017, 8:00pm

GUI_VERSION 53202
The latest available with Cube F7 V1.7.0

SEGGER - Schoenen

Super Moderator

Date of registration: Aug 13th 2015

Posts: 309

8

Wednesday, June 21st 2017, 4:59pm

Hi,

I got the reason why the progressbars are not getting updated when the swipelist is running freely.

The reason is how emWin mages the redrawing. When moving the SWIPELIST the application gets into GUI_Delay() and calls GUI_Exec(). As long as the something needs to be redrawn emWin calls GUI_Exec(). This means that when the SWIPELIST is decelerating emWin stays in GUI_Delay() (calling GUI_Exec()) until the SWIPELIST stops. In that time the progressbars are not getting updated.

To get around of this I adapted your code. I have set a callback for the dialog (_hDialogMain) and created a timer with a period of 30ms in this callback. Each time the timer expires a new value gets set for the progressbars. The advantage is that the timer gets also handled in GUI_Exec() and it doesn't matter how long emWin stays in GUI_Delay().

Attached is the adapted code. I marked all changes with '/****/', just search for it.

Regards,
Sven
SEGGER - Schoenen has attached the following file:

inojosh

Beginner

Date of registration: Jun 1st 2017

Posts: 5

9

Wednesday, June 21st 2017, 6:13pm

Sven,

That solution does work for that particular example, but only for updating other widgets.
Does this mean a swipelist can't realistically be used without an RTOS, since it stays in GUI_Exec() until it is done moving?
In my example I was using an RTOS (albeit with no other tasks) but I am just wondering about the implication in a non-RTOS environment.