`bevy::diagnostic::FrameTimeDiagnosticsPlugin` cannot obtain true FPS with modifying `bevy::time::TimeUpdateStrategy`

[Neutron3529]

Bevy version

0.14.2

What you did

Writting down such minimal example:

use bevy::prelude::*;

fn main() {
    App::new()
        .add_plugins(bevy::diagnostic::LogDiagnosticsPlugin::default())
        .add_plugins(bevy::diagnostic::FrameTimeDiagnosticsPlugin::default())
        .add_plugins(DefaultPlugins)
        .add_systems(Startup, init)
        // .add_systems(Update, despawn)
        .run();
}

fn init(mut tus: ResMut<bevy::time::TimeUpdateStrategy>) {
    *tus = bevy::time::TimeUpdateStrategy::ManualDuration(std::time::Duration::from_secs(100));
}

What went wrong

The actual FPS (which could be calculated from the wall logging time) does not reported.
Instead, a fixed fps 0.01 is reported every frame.

$ cargo run --release
   Compiling minimal v0.1.0 (/me/bug)
    Finished `release` profile [optimized] target(s) in 2.13s
     Running `target/release/minimal`
2024-09-24T09:24:28.335904Z  INFO bevy_render::renderer: AdapterInfo { name: "NVIDIA GeForce RTX 3060 Laptop GPU", vendor: 4318, device: 9504, device_type: DiscreteGpu, driver: "NVIDIA", driver_info: "560.35.03", backend: Vulkan }
2024-09-24T09:24:28.938985Z  INFO bevy_winit::system: Creating new window "App" (Entity { index: 0, generation: 1 })
2024-09-24T09:24:28.951865Z  INFO bevy diagnostic: fps        :    0.010000   (avg 0.010000)
2024-09-24T09:24:28.951907Z  INFO bevy diagnostic: frame_time : 100000.000000ms (avg 100000.000000ms)
2024-09-24T09:24:28.951915Z  INFO bevy diagnostic: frame_count:    1.000000   (avg 0.500000)
2024-09-24T09:24:29.049511Z  INFO bevy diagnostic: fps        :    0.010000   (avg 0.010000)
2024-09-24T09:24:29.049543Z  INFO bevy diagnostic: frame_time : 100000.000000ms (avg 100000.000000ms)
2024-09-24T09:24:29.049552Z  INFO bevy diagnostic: frame_count:    2.000000   (avg 1.000000)
2024-09-24T09:24:29.062974Z  INFO bevy diagnostic: fps        :    0.010000   (avg 0.010000)

Additional information

It should be the misuse about the real time. For some meta informations, Res<Time> should not be used. Maybe bevy should provide a Time<Wall> that just wraps std::time::Instant::now() for those users who needs the wall time, or just let those user call std::time::Instant::now().

[BenjaminBrienen]

Maybe related: #14152

[Neutron3529]

Maybe related: #14152

That is not related.

The reason this bug occurs is that, Time<Real> affected by bevy::time::TimeUpdateStrategy::ManualDuration(std::time::Duration::from_secs(100));

which is definately not what the doc said (Time<Real> should be wall time)

Unfortunately, since there are guides that tell user modify Time<Real> for some multiplayer game, I have no idea whether Time<Real> should be modified.

Maybe we should correct the mechanism, makes Time<Real> unconfigurable, and TimeUpdateSchedule affects Time<Virtual> directly

[maniwani]

What are we calling the "bug" here?

This is the intended behavior. The TimeUpdateStrategy was introduced by #6159 specifically to help people write test cases that want to mock wall time.

You can see in the code that it works by directly controlling Time<Real>.

bevy/crates/bevy_time/src/lib.rs

Lines 147 to 151 in 5fcbdc1

	match update_strategy.as_ref() {
	TimeUpdateStrategy::Automatic => real_time.update_with_instant(new_time),
	TimeUpdateStrategy::ManualInstant(instant) => real_time.update_with_instant(*instant),
	TimeUpdateStrategy::ManualDuration(duration) => real_time.update_with_duration(*duration),
	}

Making Time<Real> non-configurable would be regressive. This seems like a documentation issue.