Added opengl support for --format png output

[k4pran]

Overview: What does this pull request change?

Added opengl support for outputing pngs using the --format png flag.

Motivation and Explanation: Why and how do your changes improve the library?

#1970

Currently png output is only available for cairo. This PR extends it to opengl.

Links to added or changed documentation pages

Further Information and Comments

This PR makes some changes to the behaviour of dry_run, from what I can tell the getter and setter were using old configs self.save_pngs and self.save_as_gif meaning that it was enabling dry run when --format png or --format gif were used. I couldn't see any negative affects but I guess as part of reviewing it is worth looking out for any consequences of this change.

Another point about this PR is related to interactive mode, there are cases were calling interactive_mode() does not have any affect, such as when write_to_movie is set or animations are disabled. I extended this to include --format png and in cases where the window has not been initialized as it errors in the latter case.

I added a check for context before using a cached program, this is because if multiple tests run it will render multiple scenes and create multiple contexts. It will fail with an error if you try to use a cached program that belongs to another context.

Reviewer Checklist

• The PR title is descriptive enough for the changelog, and the PR is labeled correctly
• If applicable: newly added non-private functions and classes have a docstring including a short summary and a PARAMETERS section
• If applicable: newly added functions and classes are tested

[hydrobeam]

This PR really cleans up a lot of the flags for opengl, great work!

I'm of the opinion that calling a scene with no flags should effectively call self.interactive_embed() so that the -p flag does one job, but that can be handled in another PR 🤔

[hydrobeam]

This seems like it makes so that --write_to_movie makes it so that the window no longer pops up, which I think is a good idea. However, being able to adjust the scene manually while it's recording is a neat (albeit niche) feature for debugging. Maybe a flag like --force_window (or anything) to let the window exist while --write_to_movie is recording?

[k4pran]

Yea sounds good, I will look at adding a flag for this!

[k4pran]

@hydrobeam was this ever possible to do? It seems to cause other issues, for example, caching means that frames will be not written to the opengl window, and when you try to write a movie at the same time as render to the window it also causes ValueError: write to closed file. It works with pngs but performance is really slow

EDIT: Fixed the ValueError by checking if the pipe is closed, not sure about caching though, unless you think it is ok to force disable caching when force_window is enabled?

EDIT again: I added some tests for force_window flag, but discovered another issue testing opengl, it seems running multiple opengl tests result in it trying to reuse the context which then fails so had to mark the last test xfail. They work when running individually

[k4pran]

@naveen521kk I added this argument as it seems like it would allow parallelization but, for tests in the same file they would share a worker to avoid issues with multiple opengl windows running at the same time. Does this make sense to you? got the information here - https://stackoverflow.com/questions/4637036/is-there-a-way-to-control-how-pytest-xdist-runs-tests-in-parallel

[naveen521kk]

Looks good

[hydrobeam]

I was doing some testing and --force_window works as expected! Although, I also noticed that when calling a scene with animations via with -ps (and/or) --write_to_movie, the window pops up and animations are played (although the file is saved as a png at the end of the anims).

I'm not sure if this is in the scope of this PR, but here's the code i used to test:

manim -ps mkt.py --renderer=opengl MTV --disable_caching --write_to_movie

class MTV(Scene):
    def construct(self):
        def f(x):
            return x ** 2

        table_x = np.array([0, 1, 2, 3, 4])
        table_data = np.array([table_x, list(map(f, table_x))])
        print(f"{table_data=}")

        table = DecimalTable(table_data, row_labels=[MathTex("x"), MathTex("f(x)")])
        self.add(table)
        s = OpenGLVMobject(
            fill_opacity=0.3,
            fill_color=GREEN,
            stroke_width=0,
        )
        s.points= table.get_cell((1,2)).points 

        length = len(table.get_entries_without_labels())

        for ent in range(length):
            pos =(min(ent//5 + 1, 2), min(ent%5 + 2,6))
            curr_cell = table.get_cell(pos)

            self.play(s.animate.set_points(curr_cell.points))

[k4pran]

I was doing some testing and --force_window works as expected! Although, I also noticed that when calling a scene with animations via with -ps (and/or) --write_to_movie, the window pops up and animations are played (although the file is saved as a png at the end of the anims).

I'm not sure if this is in the scope of this PR, but here's the code i used to test:

manim -ps mkt.py --renderer=opengl MTV --disable_caching --write_to_movie

class MTV(Scene):
    def construct(self):
        def f(x):
            return x ** 2

        table_x = np.array([0, 1, 2, 3, 4])
        table_data = np.array([table_x, list(map(f, table_x))])
        print(f"{table_data=}")

        table = DecimalTable(table_data, row_labels=[MathTex("x"), MathTex("f(x)")])
        self.add(table)
        s = OpenGLVMobject(
            fill_opacity=0.3,
            fill_color=GREEN,
            stroke_width=0,
        )
        s.points= table.get_cell((1,2)).points 

        length = len(table.get_entries_without_labels())

        for ent in range(length):
            pos =(min(ent//5 + 1, 2), min(ent%5 + 2,6))
            curr_cell = table.get_cell(pos)

            self.play(s.animate.set_points(curr_cell.points))

Yea I think it is in scope, I fixed it if you want to try again. One other thing I am wondering, the logic as it stands means that if we omit the -p flag and any ouputs like png or write_to_movie, and use interactive_embed, the window will not be created. Seems like interactive_embed shouldn't rely on -p what do you think? So many permutations of this lol. I opened a discussion btw here - #2010. Not related as much to these scenarios, but it is the same idea. Config is creating a lot of permutations, maybe we should start agreeing on what makes most sense and creating various modes or something to avoid needing to have a string of if statements each time. Created an issue #2069 to improve handling of these scenarios

[hydrobeam]

Just tested it out and it works more in line with what one would expect 👍. Although the behaviour isn't perfect atm in my opinion, this PR is a huge step up and shouldn't be stalled further. I've outlined how I think we should handle the flags as a whole in #2069 . LGTM!