Opengl Cairo Renderer Comparison

The purpose of this page is to document differences between the Opengl and Cairo in manim to assess if we can abstract them away and make it easier to maintain them both.

OpenGLRenderer and CairoRenderer classes

Similarities

Below are the similar methods that would make sense to abstract as they are called outside the renderer classes

• init_scene method to initialize the renderer
• play method to run the animation, however these have compatibility issues - see the Differences section.
• render method to render the scene
• get_frame method
• scene_finished method after scene has completed
• num_plays attribute that is used a lot by Scene class
• Each renderer has a SceneFileWriter object that is used by Scene

Differences

Differences	Suggestions	Comments
Opengl play method still using old style annotations handle_caching_play and handle_play_like_call.	Should be refactored to not rely on these annotations
render methods not using the same parameters	Common signature that makes sense for all renderers	moving_mobjects only used by cairo, time only used by opengl
Only opengl has clear_screen method	We could have hooks such as before_render, after_render to make it more generic or use scene_finished if possible
Both renderers use different types of cameras	Could also create an abstract Camera class
Only the opengl renderer has a window and interactive modes	Could move window and interactive logic inside the opengl renderer
Scene references an attribute time in add_sound only available to cairo	Add similar sound support in opengl?	See #2144

In general it seems there are some common methods that would make sense create a base class that renderers must extend such as render, play, init_scene and some other hooks that are called before and after important stages such as before_render and after_render. The Scene class can then just call these in order and not be concerned about the implementation. There is also a lot of logic in the Scene class that would make more sense in the renderer such as handling the window and interactive modes, as Scene shouldn't have logic only specific to one renderer.