- Project: Custom Performance Monitors and Custom Profilers in Godot Engine
- Student: Utkarsh (simpuid)
- Mentors: Fabio Alessandrelli (Faless) and Max Hilbrunner (mhilbrunner)
- Branches: Custom Monitors and Custom Profilers
- PR: Custom Monitors(merged) and Custom Profilers
Performance Monitors are used to measuring various parameters like frame rate, physics time, draw call, etc. But they are limited to a bunch of predefined parameters. With custom monitors users can monitor a user-defined parameter together with the predefined ones. The only difference is that they appear inside the editor after running the game.
Godot has profiler, visual profiler, network profiler, and performance profiler. They use a messaging system to communicate between the editor and the running game. Custom profilers exposes that system to GDScript so users can add their profiler in the form of a plugin. If you want to profile something that can't be done using a custom monitor, you can make a custom profiler for it.
Implementation of the custom monitor is complete and merged to master (#39302). You can check that out now otherwise continue reading.
Custom monitors can be added/removed/checked using the Performance class. You register a Callable as one of the monitors. The game calls that callable at each profiler tick (performance profiler's tick in this case) and sends the returned data to the editor together with data of predefined monitors. You can find some example code in the PR and check the docs of Performance class (Not updated at the time of writing).
You can also assign a category to custom monitors and organize them and you can also read the previous value of monitor graph by clicking LMB on them (suggested by samdze)
Implementation of custom profilers is complete but not merged (#39440, things are working so far). It is an API to expose the messaging system used by profilers in Godot so it involves multiple classes. There is EditorDebuggerNode which handles the task of instancing and removing the GUI scenes of custom profilers in the editor. ScriptEditorDebugger to handle the editor side of the custom profiler. EngineDebugger manages the game side of the custom profiler.
Adding the GUI scene of the custom profiler may seem odd at first (because we are using a packed scene instead of a node instance). Godot can debug multiple instances of the game concurrently so we need multiple instances of the profiler. EditorDebuggerNode manages this task for you. That's why we need a packed scene instead of a node instance.
Sending a message between the editor and the game is done insend_message function, but receiving them is not that simple. You need to register a Callable to receive messages. ScriptEditorDebugger calls the callable when it receives a message. The same goes for EngineDebugger.
There is an example to demonstrate the working of a custom profiler.
The yellow crosshair represents the mouse position relative to the game window. The "Remote Execute" button executes the text as an expression in the game. You can see the label change after remote execution.
The custom profiler PR may need some refactors before the merge. Meanwhile, I shall implement/expose extra functions that would help in the implementation of the custom profilers. After the merge, I can start working on moving the hard-coded parts of other profilers from ScriptEditorDebugger to their respective classes.
