Open alice-i-cecile opened 8 months ago
I believe this should be in the bevy_diagnostic
as it collects data. But some sort of visualization of this data should be in the bevy_dev_tools
We could also consider moving this code to bevy_diagnostics, but similar problems arise. It also creates a painful dependency from bevy_render to bevy_diagnostics, when we want the dependency to flow the opposite direction, for both compile time and architectural reasons.
Chewed on this choice too :) I've since changed my mind about what the best course of action is here and I've updated the original issue to match.
What problem does this solve or what need does it fill?
Added in #9135, this is fundamentally a tool used by developers to inspect their game.
It should be integrated with bevy_dev_tools for:
What solution would you like?
Once #9135 is merged, add an integration, adding an on-by-default feature flag. We can probably combine this with the frame-time tool: @matiqo15 and I agree that this sort of timing / performance information should be integrated and displayed cohesively.
If #12427 is also merged, implement the standard dev tools abstraction for it as well.
What alternatives have you considered?
Initially I thought it might be correct to move the initial code to bevy_dev_tools entirely. However:
a) it's tightly integrated with the rest of the renderer b) it doesn't contain any native ways to display this information, that might be toggled or configured like the other dev tools
We could also consider moving this code to bevy_diagnostics, but similar problems arise. It also creates a painful dependency from bevy_render to bevy_diagnostics, when we want the dependency to flow the opposite direction, for both compile time and architectural reasons.