Write seems to be highly dependent from the OS making it untestable

[huguesdevimeux]

I'm facing an incomprehensible issue with Write function.
To give a little bit of context, I'm building tests (yes, still ... ) and so those tests are run on different OS (Linux - MacOs - Windows).
To test Write, I just compare the last frame generated with a pre-generated one: if it matches, all good, if not, something has been modified/broken.

BUT The Write test passes only on windows (see, for example, https://github.com/ManimCommunity/manim/runs/772124858). So I first thought "Well, it's normal, since my Write test works with a Text object, it must be a font-related issue since the fonts are different from a system to another, and I generated the pre-rendered frames on windows so it's logic. But no, because the Text test (that just test Text object, no animation (see

manim/tests/test_writing.py

Line 13 in b38d00a

class TextMobjectTest(Scene):

) works on any system. I precise that the frame differs from -I think - a bunch of pixels - the difference does not seem to be visible.

So my guess is that the issue comes from Write directly. I tried to implement something that changes the data depending on the system we are testing on (i.e if on Linux, take the pre-rendered frame from Linux, etc) but nah, it didn't work on both macOS and Ubuntu. (But worked on windows).

So I think I will purely remove this test. (If you agree, of course)

But my question is: Does anyone knows why does that happen?

[Aathish04]

Sometimes the creation/addition/removal isn't completed fully at the end of the animation. Ive had this happen sometimes, with my own animations and to solve it I add a self.wait(1) after the animation so Manim can finish things properly.

You can see this here, where I've used an Uncreate():

The GIF keeps looping but you can see that the word "The" is only partially uncreated.

Adding a self.wait() at the end made this issue go away.

Perhaps this is a similar problem?

[huguesdevimeux]

@Aathish04 Thank you very much for that, but sadly it does not work either.
I really don't know where does this come from.

So for the moment, I will just remove this test. I'll put a comment referring to this issue instead.
If someone knows something, don't hesitate!

[leotrs]

@Aathish04 This sounds like a bug, doesn't it? Could you pretty please create a new issue about this and attach the same gif? Thanks :)

[leotrs]

@huguesdevimeux where is Write defined?

[Aathish04]

@huguesdevimeux where is Write defined?

https://www.github.com/ManimCommunity/manim/tree/master/manim%2Fanimation%2Fcreation.py#L100

[Aathish04]

@Aathish04 This sounds like a bug, doesn't it? Could you pretty please create a new issue about this and attach the same gif? Thanks :)

Will do, but is just demonstrating it with Uncreate() enough or will I have to mention that it doesn't work for all similar animations?

[leotrs]

https://www.github.com/ManimCommunity/manim/tree/master/manim%2Fanimation%2Fcreation.py#L100

Thanks. The problem of using import * everywhere is I can't even see where anything is defined...

Will do, but is just demonstrating it with Uncreate() enough or will I have to mention that it doesn't work for all similar animations?

I mean just posting the exat same gif will do if you're in a hurry. If you have a bit more time, then I'd ask you to post a small code example that also exhibits the same problem (and perhaps a gif of it while you're at it) :)

[TonyCrane]

Have you tried to Write some other mobjects generated internally by manim (such as Square, Circle, Dot, etc.)?

I think it may be because different machines (or different systems) generate different svg problems, not Write's problems.
For example: Text is generated by cairo, and TexMobject is generated by latex and dvisvgm. Different versions of cairo, dvisvgm or different systems may result in different generated svg and different point sets.
While Square and other mobjects are only generated from within manim, their point sets must be the same.

So I suggest you compare the performance of Write these mobjects(generated by manim) on different systems.

[TonyCrane]

And it's not just Write. If you don't add self.wait to other animations, some content may be missing at the end as well.

[leotrs]

Yes it would appear that the problem is the parent class, DrawBorderThenFill

[huguesdevimeux]

An update :

It appears that the last letter is slightly more transparent in some os. For example :

(left : rendered on Ubuntu 18.04 / right : On windows 10)
Here the d is slightly more transparent in the left-hand image than in the right hand one. In fact, the last frame seems to be skipped in the left-hand image, making the last letter a bit transparent.
(full credit to the great @leotrs who found that)

Since the code of Write is very basic, the issue comes presumably from DrawBorderThenFill.

My hypothesis is that this whole issue comes from the Progressbar.
Indeed, Seeing those lines

        for t in self.get_animation_time_progression(animations):
            dt = t - last_t
            last_t = t
            for animation in animations:
                animation.update_mobjects(dt)
                alpha = t / animation.run_time
                animation.interpolate(alpha)
            self.update_mobjects(dt)

the t values used to update objects during the animations are taken from get_animation_time_progression, which returns ... a ProgressDisplay object (from tdqm library, used to do the CommandLine ProgressBar).
So for me, the issue is quite simple, tdqm behaves differently depending on the system, and in this case the last t value is either skipped or rounded down.

I will try this asap.

[leotrs]

I've never used tqdm myself so my question is: is it orthodox/expected/good practice to determine the course of a program by querying the progress bar itself? I'm not sure how this works at all.

It'd be much more reasonable I think for manim to determine its own course of action and then tell the progress bar to reflect that, instead of the other way around. Or am I missing something?

[huguesdevimeux]

REMINDER : Do not close this issue until a test is set up for Write. For the moment, in #133 , WriteTest has been ommitted.

[huguesdevimeux]

@leotrs Tbh I didn't use it either, but like that this does seem very orthodox. I agree with your idea.

An update: It appears that my hypothesis is seemingly untrue. The t values are the same on every system. If someone wants to conduct a deeper investigation, feel free!

[leotrs]

This sort of got derailed into discussing a bug that is now documented in #183 and I am currently working on #698

Is there an issue with Write that is independent of this?

[huguesdevimeux]

@leotrs Well I don't really know.
To be honest I don't even think it's related to t values, but rather to the SVG thing that does not provide the same vectorized images for a certain t value on several systems. I say that because t values are consistent over the systems.

(and btw if you choose to fix 698 by adding a new frame at the end of the video (whoch I don't really mind), it won't definitely solve this issue).

[leotrs]

I see. I think this (and possibly many other bugs) will be revealed once we have video tests (#618 ). We're not too far away from getting those.