[BUG] HTML animations show final frame when executed for the second time

[svandenhaute]

Terms

• Checked the existing issues and discussions to see if my issue had not already been reported;
• Checked the frequently asked questions;
• Read the installation instructions;
• Created a virtual environment in which I can reproduce my bug;

Describe the issue

I have rendered it using manim-slides render scene.py CreateCircle, after which I convert to HTML using manim-slides convert CreateCircle slide.html. I can open slide.html just fine in any browser, and play the animation for the first time just fine, with a quality and smoothness that is satisfactory. However, when I use the arrows to go backwards through the slides and then move forward again, each animation I think starts from the last frame in the corresponding mp4, before realizing it should reset to the start and play. This makes the final state of the animation appear and disappear very quickly for each animation.
It seems like a caching issue because it does not happen when I first go through the slides.

Slides were created on the following machine:

OS: Fedora 40
Python 3.10.14
manim                       0.18.1
manim-slides                5.2.0

The issue is observed on Fedora 40 (Linux and Thorium browsers) as well as Windows 11 (Edge browser).

Command

manim-slides convert CreateCircle slide.html

Issue Type

Visual bug when presenting (manim-slides present)

Python version

Python 3.10.14

Python environment

Manim Slides version: 5.2.0
Python executable: /home/svandenhaute/micromamba/envs/psiflow_env/bin/python3.10
Manim bindings:
	manim (version: 0.18.1)
	manimgl not found
Qt API: pyqt6 (version: 6.7.1)

What is your platform?

Linux, Windows

Other platform

No response

Manim Slides Python code

from manim import (
    Scene, Create,
    Circle, Square,
    Transform, FadeOut,
)
from manim_slides import Slide


class CreateCircle(Slide):

    def construct(self):
        square = Square()
        circle = Circle()

        self.play(Create(square))
        self.next_slide()

        self.play(Transform(square, circle))
        self.next_slide()

        self.play(Transform(square, Square()))
        self.next_slide()

Relevant log output

No response

Screenshots

No response

Additional information

No response

Recommended fix or suggestions

No response

[jeertmans]

Hi @svandenhaute, thanks for posting your issue!

I guess you ticked the wrong issue type here

Visual bug when presenting (manim-slides present)

as mentioned that the bug occurs when converting to HTML (and playing slides)?

I could reproduce your issue, and there is nothing I can really do about this, as this is related to how RevealJS handles playing videos. The best you can do is repost this issue in https://github.com/hakimel/reveal.js and see if they can do something.

Note that the bug doesn't seem to occur when setting -cdata_uri=true (warning: the -cdata_uri option will be deprecated in favor to --one-file in the next release, see #508), which embeds all the videos into the file.

I am closing this now, but feel free to re-open if necessary.

[svandenhaute]

Thanks for the quick reply. I guess I understand that this has got to do more with RevealJS rather than manim-slides, but it does feel like a dealbreaker for the entire HTML exporting functionality of manim-slides. I do see there's not much you can do about this.

With -cdata_uri=true it almost works seamlessly, but not quite. There's still a flicker at the beginning of each animation. Are there maybe other convert flags you know of which might fix this?

[jeertmans]

From experience, you don't go often backward with slides and, when you do, it feels more natural to expect a small flash in the slides, than going forward, especially as you usually don't have a continuum between the start of slide n and the start or end of slide n+1.

I am not aware of any other trick when converting, however, keep in mind that:

• lower resolution (4k is overkill in conferences, full HD is excellent, but HD is usually good enough) means faster video loading;
• performance mode (vs "battery save") is usually better, as modern CPUs usually throttle their frequency to save battery, which means everything becomes slower;
• and plugging your laptop to a power supply could enable more performance (in link to the power mode).

[svandenhaute]

I am experiencing the initial black screen "flash" even when moving forward through the slides for the first time though... Any ideas why that might be the case?

Also, for completeness sake, I'll also mention that PPTX seemd to suffer from the same bug.

[jeertmans]

Unfortunately, I cannot reproduce (I am on a rather powerful machine, so that could explain).

I will release a new version with #508, as this contains an improvement that could fix your issue.

[jeertmans]

See https://github.com/jeertmans/manim-slides/releases/tag/v5.3.0.

[svandenhaute]

That somehow fixes it and makes it butter-smooth! Thanks for the help.

In your experience, how "scalable" is the one-file HTML? Will it somehow start to get laggy for very large presentations? I'm normally planning to present on an M4 Macbook Pro so performance should be top-notch.

[jeertmans]

That somehow fixes it and makes it butter-smooth! Thanks for the help.

In your experience, how "scalable" is the one-file HTML? Will it somehow start to get laggy for very large presentations? I'm normally planning to present on an M4 Macbook Pro so performance should be top-notch.

I don't know, I have used that feature very little :-)

[svandenhaute]

Just for the record: I managed to "fix" this issue by disabling the browser cache in firefox:

browser.cache.disk.enable to False in about.config

[jeertmans]

Just for the record: I managed to "fix" this issue by disabling the browser cache in firefox:

browser.cache.disk.enable to False in about.config

Thanks for sharing!