tvg_set_frame fails on lastframe

[theashraf]

in dotLottie-rs, I'm facing an issue with a lottie animation consists of 42 total frames, and when tvg_set_frame is called in the animation loop with last_frame set to 41, it sometimes returns TVG_RESULT_INSUFFICIENT_CONDITION. This error prevents the animation from reaching its completion condition. Interestingly, this issue only occurs if the penultimate frame (pre_last_frame) is interpolated to a value very close to the last frame (for example, 40.99977). When frame interpolation is disabled, this issue does not occur.

Here is the asset link for reference: R3nSQxmVaC.json

Below is the Rust test code snippet illustrating the problem:

#[test]
fn test_set_frame_fail_for_last_frame() {
    let player = DotLottiePlayer::new(Config::default());

    assert!(
        player.load_animation_path("tests/assets/test.json", WIDTH, HEIGHT),
        "Animation should load."
    );

    let total_frames = 42.0;

    assert!(player.set_frame(total_frames - 1.0 - 0.0005), "Setting frame should pass.");
    assert_eq!(player.current_frame(), total_frames - 1.0 - 0.0005, "Current frame should match.");

    // For some reason, set_frame here fails in ThorVG with a result of 2, which corresponds to TVG_RESULT_INSUFFICIENT_CONDITION
    assert!(player.set_frame(total_frames - 1.0), "Setting the last frame should pass."); // This line fails
}

Any insights into why this might be happening?

[hermet]

It looks like a floating-point precision problem.

[hermet]

@theashraf Hello, this is a good topic to discussion. Currently, tvg ignores the frame value if the difference is less than 0.001. How could people notice changes within 1ms? In most cases, in my opinion, updating the frames when the change is less than 1ms is just an unnecessary burden on the system.

In your case, the difference is approximately 0.00023, tvg returns the false to skip the frame update by user as it's intended to use like this:

if (animation->frame( new frame value) == success) {
   //Good to update the frame.
} else {
   //Not necessarily, skip the update.
}

Thus, I suggest a more practical test:

(total_frames - 1.0 - 0.001)

or

assert(animation->frame(new frame value) != Resut::NonSupport)

Please feel free to leave your opinion if you have different thought. Thanks.

[theashraf]

Thank you, @hermet. That makes sense