Make highlighted items more visible

[elliottslaughter]

Right now we color highlighted items in red. This is not very visible because the colors picked by the profiler backend tend to be similar, so it's not obvious what is highlighted and what is just naturally red.

There are a couple ways to deal with this but the one I suggested most recently to @lightsighter was to draw the highlight with some sort of cross-hatch pattern, so that (a) it is clearly different from everything else on the screen, no matter what color those are, and (b) hopefully it is highly visible.

I'm not 100% sure how to do that with the primitives we have available, but one option might be to draw a texture over the rectangle we're trying to highlight.

Another request by @lightsighter is to highlight only the portion of the item that was clicked. This is a bit tricky because when you click "Zoom to Item", there isn't a specific segment that is indicated. Therefore, we'll have to be careful about how we do this to maintain a distinction between the item itself and any particular segment of it.

[elliottslaughter]

Note to self: it appears that tiling just made it into egui master, so it may be some time before that option is available in a release: emilk/egui#3481

[lightsighter]

was to draw the highlight with some sort of cross-hatch pattern

Another idea is to put a highlight box around the box being drawn (red or yellow)

This is not very visible because the colors picked by the profiler backend tend to be similar

Perhaps we should consider a more muted color scheme so the highlights stand out better.

This is a bit tricky because when you click "Zoom to Item", there isn't a specific segment that is indicated.

If it would be helpful we could modify the ItemLink objects to report the interval being zoomed to instead of the interval for the whole item, which I think they default to right now.

[elliottslaughter]

There are two distinct things to work out: (a) the data model (what we want to represent), and (b) the visual representation (how to display it).

For the data model, I think there are potentially three interesting states:

1. Item only
2. Item with a point of interest (e.g., the top-level task launched a subtask at timestamp T, and we want to highlight T)
3. Item with range of interest (e.g., the top-level task entered a runtime call at point T1 and exited at point T2, we want to highlight from T1 to T2)

It would help to know which of these scenarios you think are relevant.

As for drawing it, we could either highlight the whole item and then do some additional highlight at the point/range of interest, or we could just highlight the point/range, or something else. If we choose to highlight both, we may want to rethink how we do this so it's not visually overwhelming.

[lightsighter]

It would help to know which of these scenarios you think are relevant.

1. Item only - I don't see a lot of use for this one. Usually when I click on a box I mean the part that I click on (running, waiting, ready). I don't expect it to highlight the whole task. We already report the "lifetime" field for the box so you can see how big the full thing is if you want. Perhaps we could have an "whole item" button if you really wanted to select the whole thing, but why would you want to? I at least never want the whole box. All I need to see is the lifetime and I already get that from the pop-up box.
2. Point - There's definitely a use for this one with the new "creator" feature, since you want to see exactly where in the box the creation came from, e.g. was it at the beginning, middle, end, etc.
3. Range - We should definitely have this one, but I think it only needs to extend to the degree of the running, waiting, ready ranges. If there is a different kind of range that we're interested in that should be a separate "runtime call" box, and the profiler will automatically create a waiting range in the caller box (as we already do for runtime calls currently). If you want to see the relationship between callee and caller we already have a button for that. This also has the benefit of not requiring us to overlay lots of different kinds of ranges on one box; each box has ranges with exactly one of three states, and caller-callee relationships are capture by the caller waiting for the callee to finish running. Note that if we make clicking on range only apply to that range and not the whole task, then we can add a "callee" button (right now we just have a "caller" button to avoid the case where a task/function has lots of callees).

[elliottslaughter]

So, I think we need option 1 at least in the case where the user clicks on a search result: there's no way to know exactly what part of the task they were interested in.

[elliottslaughter]

I'd ideally like to get some feedback from other users on the questions I wrote in #50 (comment)

@syamajala @mariodirenzo @rohany @jiazhihao

[rohany]

I agree that 1 is needed for search results, 2 is useful to know "when" something happened within a task, and that 3 seems like we need it but only for basic things (i.e. part of task state). More complicated use cases should have separate ranges for other recorded events.

As for potentially rendering multiple of these things at a time, I don't mind the way that nsight does it, with heavy outlines of highlighted objects and sub-objects. For point queries (i.e. when a task was launched from another task), nsight does something where it renders a highlighted vertical line at the point of the event that spans the whole screen.

[elliottslaughter]

Speaking for myself, (1) is actually what I want most of the time. For example, here's a profile:

https://legion.stanford.edu/prof-viewer/?url=https://sapling2.stanford.edu/~rupanshu/circuit_32_tracing/archive/

The CPU processor has a long-running "wrapper" task that goes repeatedly between states of running, waiting, blocked, etc. If I clicked on this task and only highlighted one segment, it would be so small that I might not be able to see it. What I'm expecting is for it to highlight the entire task on the timeline so that I can see the entire duration, and then I might zoom in and try to look around at what it's doing more specifically in one section.

I can imagine zooming in and being interested in one specific segment of a task, but to me it seems like a secondary once I can see the overall scope of a task's execution.

[lightsighter]

When it's the top-level task though the highlighted thing will be as big as almost the entire timeline. How is that useful to you? You don't have any context to know what the "interesting" part of that timeline is. If you're proposing to do (1) where it highlights the whole item, but maintain the same zoom level and center the window around the interesting point in time that might be ok, but the thing that zooms all the way out to the whole profile because the search result happens to be the top-level task is a non-starter.

I'll also not in general that once I do for application calls into the runtime that I already did for mapper calls into the runtime, then the top-level task is hardly ever going to be the result of a search/creator pan. The common case will almost always be to pan to a tiny box so we should optimize accordingly.