[BUG] next-terminates-loop flag results in quite non-smooth animations

[melyso]

Terms

• Checked the existing issues and discussions to see if my issue had not already been reported;
• Checked the [frequently asked questions]](https://manim-slides.eertmans.be/latest/faq.html);
• Read the installation instructions;
• Created a virtual environment in which I can reproduce my bug;

Describe the issue

When I set the next-terminates-loop-flag in order to let looping animations run their course smoothly before switching slides, the result is quite choppy. To be clear, it seems like it's (at least almost) doing the correct thing, but it stops the animation for a split second when the next-button is pressed (and sometimes it almost seems like it 'skips backward' a bit before playing the rest of the animation?). I'm guessing this could be a result of the animation being interrupted and then replayed for the final time from where it was first interrupted?

This may be a bit of a nitpick, but given that the idea behind the flag is to let loops finish smoothly, I think it could be important enough to open an issue on it.

Everything else (including skipping from loops to new slides without the flag) is being very responsive on my laptop, so I would be a bit surprised if it were a performance issue.

Command

manim-slides present Test

Issue Type

Visual bug when presenting (manim-slides present)

Python version

Python 3.11.11

Python environment

Manim Slides version: 5.1.10
Python executable: /Users/madserlendlyso/opt/miniconda3/envs/presentation/bin/python3.11
Manim bindings:
	manim (version: 0.18.1)
	manimgl not found
Qt API: pyside6 (version: 6.8.1)

What is your platform?

macOS

Other platform

No response

Manim Slides Python code

from manim import *
from manim_slides import Slide

class Test(Slide):
    def construct(self):
        self.play(Wait(1))
        self.next_slide(loop=True, auto_next=True)
        c = Circle()
        self.play(GrowFromCenter(c))
        self.play(Wait(1))
        self.play(ShrinkToCenter(c))
        self.next_slide()
        self.play(Wait(1))

Relevant log output

No response

Screenshots

No response

Additional information

No response

Recommended fix or suggestions

Sadly I have no concrete idea of how to fix this, but I suppose that if the issue is in fact that the animation itself gets interrupted and stitched together with the "remaining animation", maybe it could be possible to alter this behavior when the flag is set, for instance checking and potentially interrupting only when a looping animation has finished playing?

[jeertmans]

Hi @melyso, thanks for reporting this issue!

Do you have any video capture that you could include to this bug report so I can see what to problem looks like? I will also try to reproduce it locally and keep you up to date.

[melyso]

Hi! Thank you for your swift response. Here is a video capture, the next-button was pressed during the ShrinkToCenter-animation. Please let me know if you'd prefer it to be attached to the original report instead/in addition.

Screen.Recording.2024-12-15.at.10.52.37.mov

Also, I would just like to let you know that I really appreciate the work you have done here, it's a great tool you've built.

[jeertmans]

Hi @melyso, thanks for the video and your feedback. I can indeed reproduce.

Unfortunately, I don't think there is an easy solution to this.

The visual issue is caused by the following piece of code:

manim-slides/manim_slides/present/player.py

Lines 515 to 520 in 5cce117

	elif self.next_terminates_loop and self.media_player.loops() != 1:
	position = self.media_player.position()
	self.media_player.setLoops(1)
	self.media_player.stop()
	self.media_player.setPosition(position)
	self.media_player.play()

To implement the next-terminates-loop feature, I need to change the loop attribute of the video from -1 (infinite) to 1. However, changes are not applied unless I reload the media (hence, the stop). To make it look smooth, I restart the media at the last time instant (position). Even if this is relatively fast, it takes some time, and can be visible on some computes (it all depends on the frame rate and your computing resources).

If you (or anyone) find a better way to implement this feature (see QMediaPlayer's documentation), I'll be happy to receive a PR!