jakobhellermann / bevy_mod_debugdump Goto Github PK

License: Apache License 2.0

Rust 99.44% Makefile 0.56%

bevy_mod_debugdump's Introduction

bevy_mod_debugdump

Live playground: jakobhellermann.github.io/bevy_mod_debugdump

Schedule graph

use bevy::prelude::*;
use bevy::log::LogPlugin;

fn main() {
    let mut app = App::new();
    app.add_plugins(DefaultPlugins.build().disable::<LogPlugin>()); // disable LogPlugin so that you can pipe the output directly into `dot -Tsvg`
    bevy_mod_debugdump::print_schedule_graph(&mut app, Update);
}

PreUpdate schedule:

See all schedules at docs/schedule.

Render app

Render graph

use bevy::prelude::*;
use bevy::log::LogPlugin;

fn main() {
    let mut app = App::new();
    app.add_plugins(DefaultPlugins.build().disable::<LogPlugin>()); 
    bevy_mod_debugdump::print_render_graph(&mut app);
}

Extract schedule

Main render schedule

Bevy support table

bevy	bevy_mod_debugdump
0.13	0.10
0.12	0.9
0.11	0.8
0.10	0.7
0.9	0.6
0.8	0.5
0.7	0.4
0.6	0.3
0.5	0.2
0.5	0.1

bevy_mod_debugdump's People

Contributors

Stargazers

Watchers

bevy_mod_debugdump's Issues

Doesn't correctly handle cases where the same system is executed multiple times

For example: A system may be run in different stages.

I have some systems that run in multiple stages. Eg: update_console and propagate_messages below:

.add_system_to_stage(
            CoreStage::PreUpdate,
            web_server_resource::receive_console_packets
                .system()
                .label(SystemLabels::WebServerRx)
        )
        .add_system_to_stage(
            CoreStage::PreUpdate,
            update_console
                .system()
                .label(SystemLabels::UpdateConsolePreFrame)
                .after(SystemLabels::WebServerRx)
        )
        .add_system_to_stage(
            CoreStage::PreUpdate,
            propagate_messages
                .system()
                .label(SystemLabels::PropagateMessagesPreFrame)
                .after(SystemLabels::UpdateConsolePreFrame)
        )


        // And after the main logic has run, we can gather any data that needs to be sent and put it back into the wbe
        .add_system_to_stage(
            CoreStage::PostUpdate,
            propagate_messages
                .system()
                .label(SystemLabels::PropagateMessagesPostFrame)
        )
        .add_system_to_stage(
            CoreStage::PostUpdate,
            update_console
                .system()
                .label(SystemLabels::UpdateConsolePostFrame)
                .after(SystemLabels::PropagateMessagesPostFrame)
        )
        .add_system_to_stage(
            CoreStage::PostUpdate,
            web_server_resource::send_console_packets
                .system()
                .label(SystemLabels::WebServerTx)
                .after(SystemLabels::UpdateConsolePostFrame)
        )

Currently, this is incorrectly graphed as:

Notice how the the update_console and propagate_messages systems only appear once, and there is an arrow across stages send_console_packets.

Note that bevy does actually handle this correctly with teh system being scheduled multiple times. Putting a print in each system reveals the execution order:

Receiving Packet
Update Console
Propagate Message
Propagate Message
Update Console
Sending Packet

Oh, and thanks for making this tool. I can see it being super useful.

Filter system sets

I have systems that are part of small sets I'd like to ignore for the purposes of visualization. They're currently shown as independent systems with links to multiple sets, but I'd like to filter out some sets from consideration and have the systems be parented under the one that's left after the filtering.

README is out of date: `print_schedule` -> `print_schedule_graph`

The README is out of date. print_schedule needs to be replaced with print_schedule_graph.

This could be made more robust using #![doc = include_str!("../README.md")] in the crate to include the README as the docstring for the crate. Then we could test that the README compiles with cargo test --doc as a Github action! But that's probably something that should be addressed in another issue.

Errors in examples for bevy 0.12.1

Cargo.toml:

bevy =  version = "0.12.1"
bevy_mod_debugdump = "0.9.0"

Code:

use bevy::prelude::*;

...
    let mut app = App::new();

    app.add_plugins(DefaultPlugins)
        .add_systems(Startup, systems::setup)
        .add_systems(
            Update,
            (bevy::window::close_on_esc, systems::rotate_in_place),
        );


        if opt.dump_schedule {
            bevy_mod_debugdump::print_schedule_graph(&mut app, Update);
        }

        if opt.dump_render {
            bevy_mod_debugdump::print_render_graph(&mut app);
        }

It seems like there are some type alias changes or something going on here that make the re-exports in prelude unusable.

Compilation errors:

error[E0277]: the trait bound `bevy::prelude::Update: bevy_ecs::schedule::set::ScheduleLabel` is not satisfied
  --> src/main.rs:45:64
   |
45 |             bevy_mod_debugdump::print_schedule_graph(&mut app, Update);
   |             ----------------------------------------           ^^^^^^ the trait `bevy_ecs::schedule::set::ScheduleLabel` is not implemented for `bevy::prelude::Update`
   |             |
   |             required by a bound introduced by this call
   |
   = help: the following other types implement trait `bevy_ecs::schedule::set::ScheduleLabel`:
             bevy_utils::intern::Interned<(dyn bevy_ecs::schedule::set::ScheduleLabel + 'static)>
             bevy_app::main_schedule::Main
             bevy_app::main_schedule::PreStartup
             bevy_app::main_schedule::Startup
             bevy_app::main_schedule::PostStartup
             bevy_app::main_schedule::First
             bevy_app::main_schedule::PreUpdate
             bevy_app::main_schedule::StateTransition
           and 13 others
note: required by a bound in `bevy_mod_debugdump::print_schedule_graph`
  --> /home/cliff/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_mod_debugdump-0.9.0/src/lib.rs:40:65
   |
40 | pub fn print_schedule_graph(app: &mut App, schedule_label: impl ScheduleLabel) {
   |                                                                 ^^^^^^^^^^^^^ required by this bound in `print_schedule_graph`

error[E0308]: mismatched types
  --> src/main.rs:45:54
   |
45 |             bevy_mod_debugdump::print_schedule_graph(&mut app, Update);
   |             ---------------------------------------- ^^^^^^^^ expected `bevy_app::app::App`, found `bevy::prelude::App`
   |             |
   |             arguments to this function are incorrect
   |
   = note: `bevy::prelude::App` and `bevy_app::app::App` have similar names, but are actually distinct types
note: `bevy::prelude::App` is defined in crate `bevy_app`
  --> /home/cliff/dev/github/bevy/crates/bevy_app/src/app.rs:63:1
   |
63 | pub struct App {
   | ^^^^^^^^^^^^^^
note: `bevy_app::app::App` is defined in crate `bevy_app`
  --> /home/cliff/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_app-0.12.1/src/app.rs:63:1
   |
63 | pub struct App {
   | ^^^^^^^^^^^^^^
   = note: perhaps two different versions of crate `bevy_app` are being used?
note: function defined here
  --> /home/cliff/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_mod_debugdump-0.9.0/src/lib.rs:40:8
   |
40 | pub fn print_schedule_graph(app: &mut App, schedule_label: impl ScheduleLabel) {
   |        ^^^^^^^^^^^^^^^^^^^^

error[E0308]: mismatched types
  --> src/main.rs:49:52
   |
49 |             bevy_mod_debugdump::print_render_graph(&mut app);
   |             -------------------------------------- ^^^^^^^^ expected `bevy_app::app::App`, found `bevy::prelude::App`
   |             |
   |             arguments to this function are incorrect
   |
   = note: `bevy::prelude::App` and `bevy_app::app::App` have similar names, but are actually distinct types
note: `bevy::prelude::App` is defined in crate `bevy_app`
  --> /home/cliff/dev/github/bevy/crates/bevy_app/src/app.rs:63:1
   |
63 | pub struct App {
   | ^^^^^^^^^^^^^^
note: `bevy_app::app::App` is defined in crate `bevy_app`
  --> /home/cliff/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_app-0.12.1/src/app.rs:63:1
   |
63 | pub struct App {
   | ^^^^^^^^^^^^^^
   = note: perhaps two different versions of crate `bevy_app` are being used?
note: function defined here
  --> /home/cliff/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_mod_debugdump-0.9.0/src/lib.rs:82:8
   |
82 | pub fn print_render_graph(app: &mut App) {
   |        ^^^^^^^^^^^^^^^^^^

Add sub-system graphs

In a similar way to the per crate graphs (stageless branch), it could be useful to create per area graphs. For example, right now I'm using mod_debugdump to get an idea of which are all the UI related systems and how they relate.

So, I can either check the general view (which can be improved with #13) which is noisy; or check per crate images which lack information.

The idea would be generate graphs which add together various crates, for example, for UI it could be: winit, gilrs, input, text & ui.

Doesn't correctly graph system chaining

Only the outermost system is graphed, followed by some close brackets!
I think this is because to the scheduler they appear as one system?

Add ability to visualize which Bevy systems can run in parallel?

Do you think Bevy makes it possible to introspect this? That could be very helpful as someone who works with Bevy

Support bevy 0.13

Compile errors with `default-features = false`

I'm getting the following errors when using bevy_mod_debugdump = { version = "0.7.0", default-features = false }.

error[E0433]: failed to resolve: use of undeclared crate or module `bevy_render`
 --> /home/ryan/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_mod_debugdump-0.7.0/src/schedule_graph/system_style.rs:5:5
  |
5 | use bevy_render::color::Color;
  |     ^^^^^^^^^^^ use of undeclared crate or module `bevy_render`

error[E0433]: failed to resolve: use of undeclared crate or module `bevy_render`
 --> /home/ryan/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_mod_debugdump-0.7.0/src/schedule_graph/settings.rs:4:5
  |
4 | use bevy_render::color::Color;
  |     ^^^^^^^^^^^ use of undeclared crate or module `bevy_render`

Add colored systems

I'm starting to read the Bevy codebase and I found that mod_debugdump is very useful, thanks!

I miss a couple of things though, the first one is that systems could be colored by crate. For me at least it helps to filter out the systems I'm not interested in.

It has one downside though… it's not easy task to select a good color palette, there are so much crates. I've tried using a different color per crate (with darker color for lower level ones); it works but as mentioned adding new color will be a challenge. Another option is to use the same color per area, e.g.: ui and text; or render and pbr could share color.

Other styling changes I've done:

add custom styling for apply_system_buffers, so it looks bolder
tweak sets styling
color events based on the event type crate

Would you be interested in a PR for this?
(if I prepare something, label/border color will have the correct constrast/tint)

Broken

Thanks for the open source, but samples from the readme are broken.

Playground tracking issue / feature requests

https://jakobhellermann.github.io/bevy_mod_debugdump/?schedule=Main&include=bevy_render,bevy_pbr
Code at https://github.com/jakobhellermann/bevy_mod_debugdump/tree/pages

share link and load options from URL params
select schedule, includes and excludes
filter by copmonent access
make zoom work

Can't use the print_schedule function

Hi
I found the crate really useful, but when i want to print a graph of all my scheduling. I just have this error:
thread 'main' panicked at 'assertion failed: found', /home/miyoarch/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_mod_debugdump-0.6.0/src/schedule_graph.rs:437:9

So i've run so test, the main problem come from the EditorPlugin of the crate bevy_editor_pls (if i remove it, it work)
I just wanted to signal it.
Here is the code i used:
let mut app = App::new(); app.add_plugins(DefaultPlugins.build().disable::<LogPlugin>()) .add_plugin(EditorPlugin) **// It's the culprit** .insert_resource(MapSize(size, None)) .add_startup_system(generate_mesh) .add_startup_system(init_erode) .add_startup_system_set_to_stage( StartupStage::PreStartup, SystemSet::new() .with_system(generate_heighmap) .with_system(spawn_erode), ) .add_startup_system(generate_camera) .add_system(use_erode); bevy_mod_debugdump::print_schedule(&mut app); //bevy_mod_debugdump::print_render_graph(&mut app); app.run();

Also i was wondering if the "custom" stages can appear, or if there is a way to show the startup function?

Schedule ordering unreadable

The arrows (which I assume are the system ordering) in print_schedule all merge together in the left-hand side and the information is not helpful. I'm aware some of this is the idiosyncrasies of dot, but it'd be nice to find a way to make it readable. Each arrow gets a new distinct colour?

Visualize multiple schedules in a single graph

I would like to be able to display 2 nested schedules inside a single graph. I have the following graph for the FixedUpdate schedule with 4 different SystemSets

And run_solver_schedule is defined something like this

fn run_solver_schedule(world: &mut World) {
    for _ in 0..2 {
        world.run_schedule(SolverSchedule);
    }
}

And SolverSchedule has the following graph

Is there currently a way to do this?

Incompatability with iyes_loopless

It's not a big problem, I suppose, but bevy_mod_debugdump gets super confused when it meets iyes_loopless's data in the schedule graph:

It just formats the StateTransitionStageLabel in an user unfriendly way
It can't print the systems the StateTransitionStage contains, because it doesn't expose any interface for that AND doesn't fall into either of the cases bevy_mod_debugdump tries in its implementation, since iyes_loopless uses its own custom stage type.

Panic due to unwrap of None on src/schedule_graph/mod.rs:596

Happened between my last two project's commits, was using this fine before.

Full stack trace:

panicked at 'called `Option::unwrap()` on a `None` value', /Users/tfp/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_mod_debugdump-0.7.0/src/schedule_graph/mod.rs:596:27

Stack:

Error
    at imports.wbg.__wbg_new_abda76e883ba8a5f (http://localhost:8770/api/wasm.js:378:13)
    at __wbg_new_abda76e883ba8a5f externref shim (http://localhost:8770/api/wasm.wasm:wasm-function[40185]:0x11657c3)
    at console_error_panic_hook::hook::h87c767ff6c9aa7f7 (http://localhost:8770/api/wasm.wasm:wasm-function[11437]:0xccc55b)
    at core::ops::function::Fn::call::h97e0e8b91e1d35b5 (http://localhost:8770/api/wasm.wasm:wasm-function[55099]:0x11a5f23)
    at std::panicking::rust_panic_with_hook::h00df10c1b877177e (http://localhost:8770/api/wasm.wasm:wasm-function[19386]:0xf42803)
    at std::panicking::begin_panic_handler::{{closure}}::h18050073fecbd1cc (http://localhost:8770/api/wasm.wasm:wasm-function[22296]:0xfcc29e)
    at std::sys_common::backtrace::__rust_end_short_backtrace::h2ab0e48305983289 (http://localhost:8770/api/wasm.wasm:wasm-function[35944]:0x11437b4)
    at rust_begin_unwind (http://localhost:8770/api/wasm.wasm:wasm-function[30350]:0x10e0463)
    at core::panicking::panic_fmt::h4371046c91cc0cbc (http://localhost:8770/api/wasm.wasm:wasm-function[34308]:0x112c984)
    at core::panicking::panic::h9782141a857ffa9c (http://localhost:8770/api/wasm.wasm:wasm-function[31277]:0x10f4f28)

I'm not sure how to get a better trace-- using WASM in release mode with debug = true set for the release profile in Cargo.toml.

This happens when dumping a custom schedule like this:

let tick_graph_dot = bevy_mod_debugdump::schedule_graph_dot(app,
    TickSchedule,
    &bevy_mod_debugdump::schedule_graph::Settings::default());

My schedule is too complex to put here, so maybe I can try to make a minimal case to replicate with if this isn't enough.