Feedback add selection detail in the profiler timeline

Hi Laurent,

Thank you for the feedback. The Hierarchy Details view, specifically the Related Data view, list object names that where recorded as associated with a sample. This only works in the editor right now, making it work when recording a player is something we're actively trying to find a solution to. It also only works if that specific profiler sample was coded to include the UnityEngine.Object and I'm doubting that that's happening for the Sphere casts as those don't need to relate to one.

So, the Profiler in general has no more info on this, irregardless of the view. So you can only get more info via Deep Profiling or additional ProfilerMarkers in your Interaction.LateUpdate script or wherever you are calling Physics.SphereCast from. You can surround it with profiler markers and provide the context object yourself via ProfilerMarker.Begin(obj) and then see that object name in the Profiler.

We've put some of the Related Data info, also called MetaData in the API, into the timeline view selection tooltip already, not 100% sure if that includes context objects right now but that would be something to add indeed if missing, especially once that works for player profiling too. We also have generally the idea to improve the details given to a selection in Timeline view. Is there anything else that you think should be shown in there?

 

Technically it's not really a tooltip. It doesn't open on hover but on selection and then shows Info relevant to the selection. It's essentially a floating details panel that we still need to detach a bit more from the selected sample bar. That's part of what I alluded to when saying we have ideas to improve this. Detach it and add more info to it and make it that details panel you want.

The drop-down menu in there was added mostly to allow toggling of the full details call stacks in context, and to open the selected sample stack window that was added so you can copy that stack and explore how the approximation logic came to show this sample as selected, if you technically had selected a sample deeper in the stack in a different frame. That approximation logic is essentially something the Hierarchy was always doing before but in 2021.1, we fixed up the way selections work in the CPU and GPU. Now both views behave the same and try to match what is shown as selected as best as possible across the views and frames. It does that automatically so you could just switch the view as you would normally with the view drop-down in the top left of the view, but since that drop-down was already there, there was an outstanding ask to get a quicker "show me this in another view" and it could reduce mouse travel a bit, I just slapped the view switch options in there too. It's an additional option to switch the views, not the only one.

All of these changes, the ones centered around "fixing" the selection permanence, already resulted in a >100 changesets big merge request (and will therefore not get backported) and over 8 months of work (not kidding, biggest can of worms I opened so far. The extensive functional and performance test suit I wrote for this uncovered at least 3 further, already existing bugs). Reworking the "tooltip" into a details panel was simply out of scope at this point and deferred to a later point in time.

Do you mean just the process of switching the target to Playmode, switching to Editor, or switching the Playmode or Editor attached profiler to Deep Profiling?

If the later, it should scale with the amount of managed functions and also relates to compile times, as every managed assembly needs to be recompiled with profiler hooks placed into every function call during IL post processing. So, if the time that takes grew, it's likely a full recompile has also gotten slower and that maybe there are more managed calls?

 

Sorry forgot to answer to that part.
TBH, right now neither of them are perfomant enough that you'd be having a good time with them open simultaneously.
At some point I'd like all details panels to be dock able windows, so that would allow for this use case while giving you all the flexibility you know from the unity editor. We're thinking of tackling this along with the needed rework to allow for multiple Profiler Windows, tapping into different data streams. Beside questions of their performance, we'd therefore also need there to be a clear guidance as to which profiler Window these undocked windows relate to. None of this work is planned out yet and won't be for at least a year more though...