Swipelist blocks while decelerating

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

  • 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?

  • 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
    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.

  • 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).
    Files

    • swipelist.txt

      (6.56 kB, downloaded 489 times, last: )

    The post was edited 2 times, last by inojosh ().

  • 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
    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.

  • 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

  • Hi,

    Which version of emWin are you using?

    This information can be found in GUI_Version.h.

    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,

    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
    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.

  • 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.