Render commands

[Brian-Jiang]

No description provided.

[Copilot]

Pull Request Overview

This PR introduces render command support by refactoring drawing logic across the visualization engine. Key changes include adding an abstract execute_command_list method in the visualization engine interface, refactoring artists to store and use render commands, and updating default drawers and the pygame engine to build and execute command lists.

Reviewed Changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
gamms/typing/visualization_engine.py	Added abstract execute_command_list to support render commands
gamms/typing/render_command.py	Introduced IRenderCommand interface and RenderOpCode enum
gamms/typing/artist.py	Renamed visibility and drawing methods; added render_commands property
gamms/VisualizationEngine/render_manager.py	Updated rendering logic to execute command lists
gamms/VisualizationEngine/pygame_engine.py	Added command list execution logic; removed force_no_aa parameter
gamms/VisualizationEngine/default_drawers.py	Modified drawers to return render commands instead of drawing directly
gamms/VisualizationEngine/artist.py	Updated artist drawing method to generate and cache render commands
examples/custom_drawers/game.py	Updated custom drawer to return render commands instead of immediate drawing

Comments suppressed due to low confidence (2)

gamms/VisualizationEngine/pygame_engine.py:400

• Confirm that the removal of the 'force_no_aa' parameter is intentional, as this change modifies the anti-aliasing override behavior during line rendering.

                    width: int=1, is_aa: bool=False, perform_culling_test: bool=True):

gamms/VisualizationEngine/artist.py:14

• [nitpick] Consider whether the default value of '_is_rendering' should be True, as this may prevent the artist from drawing unless the 'force' flag is used.

        self._is_rendering = True

[bridgesign]

Changing the calls themselves to render commands will cause breaking changes in user code. Instead, if we shift the render command part to the call ctx.visual.render_circle might be better. To do this, we will have to change where ctx.visual points to. Rather than pointing directly to the PyGame or NoVis engine, it should point to something that creates the commands and then uses the actual PyGame or NoVis object to get the actual implementation of the method.

[Brian-Jiang]

Changing the calls themselves to render commands will cause breaking changes in user code. Instead, if we shift the render command part to the call ctx.visual.render_circle might be better. To do this, we will have to change where ctx.visual points to. Rather than pointing directly to the PyGame or NoVis engine, it should point to something that creates the commands and then uses the actual PyGame or NoVis object to get the actual implementation of the method.

Understand, I'll check what's the best way to modify this so that users won't have breaking changes.