Repository navigation
More structured output for debug marks (equivalent to glPushDebugGroup) #172
Description
Activity
I ll see what I can do next week end for this one, I did a bunch of house keeping but would need more time for this one.
Support for
glPushDebugGroupwould be very useful.As a very partial workaround, I made an RAII helper you can use like this in C++:
{ SpectorMarker marker("drawing trees"); for (....) { SpectorMarker marker("drawing tree " + std::to_string(n)); } }In the Spector UI this would display a little stack in front of every GL call like:
drawing trees drawing tree 193 glBindVertexArray: WebGLVertexArrayObject - ID: 4It's leveraging the fact that the marker labels can be long and can contain newlines.
This is massively redundant in the UI, but it does give you contextual information for each call. I'm just now seeing the
__SPECTOR_Metadatathing, maybe that could be used in addition or instead. I post this hoping someone has a better workaround!
In desktop GL, there's
glPushDebugGroupandglPopDebugGroupwhich work similar towindow.spector.setMarkerandwindow.spector.clearMarker.However, the GL way of doing it is better, because it's structured. It's possible to contain one group in another one.
Most debugging tools will visualize these groups with foldable-log entries.
This makes it possible to get a high-level overview of each rendering step in a folded/collapsed list. Users can unfold/uncollapse individual entries, and do this recursively until they find the draw calls they care about.
With projects like https://github.com/maplibre/maplibre-gl-js (map rendering) there can be hundreds of layers (water, grass, roads, ..) on a map. With groups, one could collapse these layers. Within each layers, one could have other high-level entries like "data-upload" and "rendering".
For the desktop variant of mapbox (which maplibre is based on), this is already done with debug-groups.
In GPU or API emulators it's possible to represent guest-system graphics actions by a handful of host-system API calls. So grouping these together can provide a guest-API view. (Example: When porting an application, creating a group for Direct3D draw calls, which internally call OpenGL backend functions - in collapsed view, only the Direct3D API would be shown).
However, there are probably many other applications for this.
This would also be necessary for #170.