FlareActor is constantly ticking and requesting for frames when the animation doesn't have duration

[nt4f04uNd]

Performance overlay logs shows me persistent ticks. Checkout 'play' and 'pause' animations in opposite to 'play_pause' and 'pause_play', which do not request new frames after they end. I assume that is not implementation related thing, because the rive itself also shows infintite "pause" control and the animation will never end (screenshot)

play_pause.zip

Is this intended to be like so? Because my assumption was that animation without duration isn't infinite, it's a static frame, am I wrong?

[nt4f04uNd]

For some reason, I had set those two static animations to be looped. Disabling it fixed the problem, but this thing still must be treated by the actor, as I see it, because it's pointless, but very battery consuming and it's easy to not notice this.

[luigi-rosso]

We don't special case 'pause/stop' conditions like this as there may be other reasons for a user to persistently/loop reset key values. For example, when layering multiple animations. It's up to the user to control this. Perhaps we could introduce some debug visualization making it clear when an artboard/actor is in persistent playback, to help users realize they may have accidentally triggered this condition.

[nt4f04uNd]

Ok, but how do I make just a still animation frame? Because now with still 'play' and 'pause' animations it just disappears for me when I touch the screen in some place. This was why I enabled looping back then.

[luigi-rosso]

Sounds like something else is happening that's causing the widget to not draw at all, or unloading the file. There are samples that show how to pause the animation (see the penguin example) that doesn't exhibit the behavior your are describing. Could you provide sample code?

[nt4f04uNd]

@luigi-rosso

Animation itself https://rive.app/a/nt4f04und/files/flare/play-pause/preview

UPD: wait i'll make a minimum repro in a few minutes

[nt4f04uNd]

@luigi-rosso here it is https://github.com/nt4f04uNd/flare_blink_bug

[luigi-rosso]

Thanks, we're looking into it!

[luigi-rosso]

Just a quick update on this, it looks like this may be related to a Flutter bug. It seems to work if you wrap the FlareActor in a ColoredBox with a solid color (like Colors.blue).

So change your AnimatedPlayPauseButtonState's build to do this:

return IconButton(
      iconSize: widget.iconSize ?? _kIconSize,
      onPressed: _handlePress,
      icon: SlideTransition(
        position: slideAnimation,
        child: ScaleTransition(
          scale: scaleAnimation,
          child: ColoredBox(
            color: Colors.blue,
            child: FlareActor(
              'assets/play_pause.flr',
              animation: _flareAnimation,
              callback: (value) {
                if (value == 'pause_play' && _flareAnimation != 'play_pause') {
                  animation = 'play';
                } else if (value == 'play_pause' &&
                    _flareAnimation != 'pause_play') {
                  animation = 'pause';
                }
              },
              color: Colors.red,
            ),
          ),
        ),
      ),
    );

We're trying to put together a repro without Flare/Rive code in order to have the Flutter team help investigate it further. We're guessing this is some new optimization Flutter is trying to do here to avoid redrawing which in this case is causing the Flare animation to disappear.

[nt4f04uNd]

@luigi-rosso ok, thanks. In addition I can say that this bug is definitely was before release 1.22, as far as I remember, because that was the version I started with the development of my app in June, where I use this animation. I didn't pay too much attention to this and just enabled looping frames, which is actually a really bad hack to fix this.

[luigi-rosso]

We have a simple repro without Flare/Rive code here: https://gist.github.com/luigi-rosso/4629c3422d8938d7ce0cf7cfcb01547c

In the meantime @nt4f04uNd please set your shapes to use srcOver instead of srcIn BlendMode and things should look correct.

[nt4f04uNd]

@luigi-rosso yep, that helped