What problem does this solve or what need does it fill?

Currently gizmos are global and are rebuilt every frame. This is fine for debugging small scenes. On big scenes, however gizmos can incur a very high performance penalty, making the app unresponsive. A notable example is collider visualization in bevy_rapier and bevy_xpbd. Colliders shapes are static, yet their gizmos are rebuilt every frame and don't use any frustum culling. This is especially bad for static geometry expressed in TriMesh colliders, which can have thousands of faces.

bevy_gizmos can't possibly handle rendering millions of dynamic lines (of which only a fraction are actually visible). Frustum culling in bevy_gizmos won't help, since it would have to run per-line, and not per-entity.

Adding retained gizmos would help with entity-related debug information, like AABBs, colliders, axis, direction vectors, etc, all of which would be needed in a future editor.

What solution would you like?

A retained API for building gizmo meshes:

• trait AppendLines or something similar would provide default implementation for all methods from today's Gizmos .
• Gizmos would implement AppendLines, so its API won't suffer breaking changes
• Gizmo asset for storing retained gizmos, either would implement AppendLines directly, or through some sort of a GizmoBuilder
• GpuGizmo would store the GPU vertex buffer for a corresponding Gizmo
• All entities with GizmoBundle { gizmo, transform, visibility } would be displayed just like regular gizmos

What alternative(s) have you considered?

• Optimizing Gizmos. It isn't clear how, though.
• Using a wireframe Mesh for gizmos. This actually sounds good, but an ergonomic API for constructing such meshes should exist (mirroring all the present Gizmos methods)

Previous work

• bevy_polyline

Extra considerations

• AABB debug rendering should probably be implemented in terms of this retained API, so that frustum culling works.
• Preferably there should be batching when drawing the same gizmo asset multiple times