[Android/Windows]: Progress View animation runtime bug

[DieSlower]

• [ X] I tried searching Solar2D forums for the solution.

There seems to be a bug in the ProgressView widget:
(https://docs.coronalabs.com/api/library/widget/newProgressView.html)

This bug can be seen if the widget is created with the isAnimated variable set to True

It seems the bar uses some form of acceleration to do its animation? In most cases there is no problem, but if the bar is at 1.0, and it is suddenly set to 0.0 when the animation retreats, it for a fraction of a second has a stutter in the beginning of the bar. It seems like the texture is projected backwards past the bars beginning because of it's momentum.

I'm attaching an animated gif with screen capture of both options:
isAnimated= true

If animation is disabled, then the bug vanishes, and the bar resets to 0 as expected.
isAnimated= false

To Reproduce
Steps to reproduce the behavior:
Create a ProgressView widget. Set its animation (isAnimated) value to true on create. Test setting its value from 0 to 1 and from 1 to 0. You should notice a texture stutter/reversal when the bar quickly approaches 0.

Then recreate the ProgressView widget with isAnimated set to false. Test setting it's value from 0 to 1 and from 1 to 0. Note that when the bar approaches 0, there is no stutter.

Target platform and where build was made:
Tested on android and windows, same effect.

[siudesu]

Related code is: https://github.com/coronalabs/framework-widget/blob/d425ae72f47b29a3da5880eebcb1111f2cdf6cd2/widgetLibrary/widget_progressView.lua#L178

Your tests make sense. Setting isAnimated flag to true and calling setProgress() while there's an existing animation (from a previous setProgress() call) will lead to unexpected visual issues, even calling setProgress() on the same frame the animation finishes.

If you're calling setProgress() on every frame until it reaches your target value then isAnimated should be false.

Internally, the widget uses the transition library. When an object is in transition, the current transition should be canceled first before dispatching a new one; the ProgressView widget can probably be improved in that area...

[DieSlower]

@siudesu I wish this was improved... your link helped me to create an override for my purposes that works well, but this really should be implemented in the widget.

I basically detect if the value of the bar is around 0, turn off the animation if it's on, set the value, then return the animation to previous state.

    ---- Common set progress function that fixes an animation bug
    function self:SetProgress(value)
        --Save animation settings
        local isAnimTemp = mProgressSliderUI._isAnimated
        
        --If the value is ~0, turn animation off and jump to the value,
        --Otherwise animate if _isAnimated=true
        if value <= 0.01 then
            if isAnimTemp then
                --Cancel and Disable internal widget animation
                transition.cancel(mProgressSliderUI._fillMiddle)
                transition.cancel(mProgressSliderUI._fillRight)
                mProgressSliderUI._isAnimated=false
            end
            mProgressSliderUI:setProgress( value )
        else
            mProgressSliderUI:setProgress( value )
        end
        
        -- Return animation settings to intial state
        mProgressSliderUI._isAnimated = isAnimTemp
    end

[siudesu]

@DieSlower , I made a proposed solution similar to yours but had a hard time trying to test the module on a standalone project.
I just forked the Widget Framework and uploaded the changes: https://github.com/siudesu/framework-widget/tree/master

The repo includes unit testing, can you please see how these changes work for you? Thanks!