Show/hide thread lanes and make them collapsible

[TimonPost]

Checkboxes for hiding and showing puffin flame graph threads.

The collection is stored in Options as it is nice for it to be saved upon application closing. Also used index map such that order is preserved, we get fast insertion and reading, and only get unique thread entries are shown in thje checkbox list. By storing it in Options we do generate an index map that gets extended longer and longer with time as all threads from all profiled puffin files/applications eventually end up in there. Tho as we still iterate through the currently selected frame threads those other threads do not show up in our checkbox list. Think its not to big of a deal.

New option to disable thread lanes:

Collapsable threads:

[gwen-lg]

On the screen the thread list seems to take a significant vertical place.
It is possible to add collapse possibility ? Like Frames display.

[TimonPost]

Maybe like a collapsable settings bar? All settings could be under this bar in a panel.

[TimonPost]

Looks nice to me with a collapsable widigty

[gwen-lg]

I think it's good to have some settings accessible without need to unfold.
I think of Help ? sort setting ? Scope Filter ?
Show thread setting could be at right instead to be at left ?

As alternative, I would like to be able to fold/unfold thread display directly in flamegraph.

[gwen-lg]

To illustrate (quick proof of concept):

And :

[TimonPost]

like that idea as well! Will give it a try and see the possibilities there

[TimonPost]

Tho need to find a way on how to persist the settings. Expect it to be a bit more tricky doing it that way.

[gwen-lg]

I don't know how persistent settings work in puffin (viewer ?).
But I used the same options.show_flamegraph_threads as you in my test.

[TimonPost]

@gwen-lg you seem to sugegest you somewhat implement it? I have it somewhat working, only missing arrows, but the whole thread section is not using egui::Ui but rather uses Painter to draw the UI. Collaps headers as it is provided by egui can only be used it seems with a proper instance of egui::UI.

[gwen-lg]

Yes, I was thinking yesterday that use Painter instead of egui::Ui have disadvantages, and perhaps isn't the best solution.

But with the existing, I have copy and adapt the code of the CollapsingHeader display. This code directly construct the arrow to display, and eventually rotate it.
Original code is in fn paint_default_icon in collapsing_header.rs.
On my side I hacked paint_thread_info like this (PS: it's not clean code, it's probably need to be improved) :

fn paint_thread_info(info: &Info, thread: &ThreadInfo, show: &mut bool, pos: Pos2) {
    let pos_arrow = pos2(pos.x + 2., pos.y + 2.);
    let rect_arrow = Rect::from_min_size(pos_arrow, vec2(8., 8.));

    // Draw a pointy triangle arrow:
    let rect_arrow = Rect::from_center_size(
        rect_arrow.center(),
        vec2(rect_arrow.width(), rect_arrow.height()) * 0.75,
    );

    let mut points = vec![
        rect_arrow.left_top(),
        rect_arrow.right_top(),
        rect_arrow.center_bottom(),
    ];
    if !*show {
        use std::f32::consts::TAU;
        let rotation = emath::Rot2::from_angle(-TAU / 4.0); //90°
        for p in &mut points {
            *p = rect_arrow.center() + rotation * (*p - rect_arrow.center());
        }
    }

    let galley = info.ctx.fonts().layout_no_wrap(
        thread.name.clone(),
        info.font_id.clone(),
        Rgba::from_white_alpha(0.9).into(),
    );
    let text_pos = pos2(pos.x + 14., pos.y);
    let rect_text = Rect::from_min_size(text_pos, galley.size());

    let rect = Rect::from_min_max(rect_arrow.min, rect_text.max);
    info.painter
        .rect_filled(rect.expand(2.0), 0.0, Rgba::from_black_alpha(0.5));
    info.painter.add(Shape::closed_line(
        points,
        Stroke::new(1., Rgba::from_white_alpha(0.9)),
    ));
    info.painter.galley(rect_text.min, galley);

    let is_hovered = if let Some(mouse_pos) = info.response.hover_pos() {
        rect.contains(mouse_pos)
    } else {
        false
    };

    if is_hovered && info.response.clicked() {
        *show = !(*show);
    }
}

An wanted part of my version is than arrow icon and thread name are a unique block, and all than block is clickable.
As example of improvement : I think it's should probably better than paint_thread_info return the information than the thread name was clicked, and the update of show variable updated in the caller method.

[gwen-lg]

My test, based on your work is also available here : https://github.com/gwen-lg/puffin/tree/hide-threads-flamegraph_test

[TimonPost]

Alright. I went for the arrows from here: https://docs.rs/egui/latest/egui/special_emojis/index.html, instead of painting them in code. Most of the UI is similar to before, but I split the settings panel into two columns.

I now have:

• Option to collapse threads.
• Option to hide threads completely.

Collapsible threads

When one clicks on thread name, the thread lane is collapsedsed.

Hiding possibility

When the checkbox is selected, the thread is completely hidden.

[gwen-lg]

@TimonPost : can you "clean" commits ?
I found it easier to do code reviews, and read history.
By squash fmt, clippy and rename commits in corresponding commit. Git-Tools-Rewriting-History
I use the git interactive rebase a lot, this help to have cleaner repot history and help future work (when you need to read history)

Note: if you use VSCode/VSCodium, you kown the "editor.formatOnSave" settings option ?
https://code.visualstudio.com/docs/getstarted/settings
This avoid to forget cargo fmt before commit/push.

[TimonPost]

Maybe can enable that config setting project-wide, but will def. do it in my own editor as well. It's indeed slightly annoying to find out that after CI ran fmt wasn't run. I squashed merged commits and rebased the branch, I dont really want to bother cleaning every single commit up as the CI will do a squash merge anyways.

[repi]

no need to clean up the commits @TimonPost , we squash merge

[emilk]

nice! what do you think about making a new release?

puffin_http could do with a patch release due to #98,
and puffin_egui and puffin_viewer a new minor release due to this PR

[TimonPost]

@emilk yes that sounds like a good idea and is in the queue. Need to update change logs and then I can do a release. Maybe I might want to sneak in a few other changes but could be done later as well.