[tui][edi] Clean up telemetry collection and reporting

[nazmulidris]

Current behavior

In the r3bl_tui crate (in the tui folder) currently telemetry data is collected by saving the time it takes to go from user input event to rendered output painted to off screen buffer in some global static mutable state.

Here's an example:

https://github.com/r3bl-org/r3bl-open-core/blob/main/tui/examples/demo/ex_app_no_layout/app_main.rs#L80

_ = time::sleep(Duration::from_millis(ANIMATION_INTERVAL_MSEC)) => {
    // Continue the animation.

    // Wire into the timing telemetry.
    telemetry_global_static::set_start_ts();

    // Send a signal to the main thread to render.
    let main_thread_channel_sender_clone = main_thread_channel_sender.clone();
    // Note: make sure to wrap the call to `send` in a `tokio::spawn()` so
    // that it doesn't block the calling thread. More info:
    // <https://tokio.rs/tokio/tutorial/channels>.
    tokio::spawn(async move {
        let _ = main_thread_channel_sender_clone
        .send(TerminalWindowMainThreadSignal::ApplyAction(AppSignal::Add))
        .await;
    });

    // Wire into the timing telemetry.
    telemetry_global_static::set_end_ts();
}

Currently this is done on an ad hoc basis. If you search for this sequence of telemetry_global_static::set_start_ts(); and telemetry_global_static::set_end_ts(); calls you will find places where this telemetry data is collected.

Currently the only way to display this data is to dump it via log output. Which is not that great, since there is no way to find out what these stats are w/out enabling logging. And logging slows down the system. So we can't really get a true measurement of "FPS" right now.

The following code is where this telemetry data ("FPS") is currently written to the log:

https://github.com/r3bl-org/r3bl-open-core/blob/main/tui/src/tui/terminal_window/main_event_loop.rs#L329

Here's a screenshot of log output when this is enabled by running ./run.nu log, while ./run.nu run is also running (each in 2 different sessions):

Desired behavior

All the tui examples here have a status bar component. It would be great to add this "FPS" metric to all the status bars.

To do so, it might be a good idea to create a telemetry module. And maybe create a declarative macro like these:

1. https://github.com/r3bl-org/r3bl-open-core/blob/main/core/src/decl_macros.rs#L57
2. https://github.com/r3bl-org/r3bl-open-core/blob/main/core/src/decl_macros.rs#L79

The idea being that you can just wrap a block of code that needs to be instrumented w/ one of these macros. The name might be measure_fps_for_this_block!() and this would simply insert calls to set_start_ts() before the block and set_end_ts() after it.

The code to generate the "FPS" counter that is used in the status bars of all the examples can also be generalized into a function that is in the telemetry module.

To summarize, here are the tasks:

• Create a telemetry module w/ a declarative macro to do instrument the timing for blocks of code.
• Use this macro in all the places in the codebase where set_start_ts() & set_end_ts() are currently used.
• Report the "FPS" metrics in each status bar in all the examples.
• For edi maybe provide a CLI flag / option that allows this to be enabled (eg --enable-stats-for-nerds like YouTube does)