Having multiple traces open in the same Tracy window.

[simonvanbernem]

I want to request the following set of features:

• Have one tracy server be able to have multiple traces open at the same time.
• Create a UI element, that shows the currently open traces, clearly shows the order in which they were recorded (possibly by just using a sorted list) and lets the user select one. The timeline, messages and so on is shown for the selected trace (just like how it currently works).
• Add a mode where tracy tries to automatically reconnect to a client that died (equivalent to the the current "reconnect" functionality that appears after one discards a trace). If the connection is successfull, the the incoming data is treaded as a new trace and added to the list of open traces.
• Add the ability to compare two currently opened traces without saving either one as a file.

I think telemetry has comparable features for some of these requests.

I suspect that this might be a very big change if the server is built with the assumption that there is only ever one trace open, but after analyzing my workflow with tracy, I think it would greatly improve my productivity with it. Currently, I am using tracy to profile an application after making some (rather small) changes to it, to see if I improved or worsened performance. The core loop currently is:

• change code, build application
• open a tracy instance, click connect
• start application, run test, close application
• compare current trace with last trace (which is opened in another tracy window)
• repeat

The issues that come up are:

• I don't use the discard and reconnect feature, because that would lose my last trace. I could save the last trace to disk, but then I'd have to pick a name (I don't want to be bothered with this in this tight loop), and I would have to reload the trace in a different instance. So opening a new tracy instance for each trace is just faster.
• When having multiple tracy instances open, it gets confusing as to what the newest trace is. I have to guess based on the profiling data or double check by reading the trace timestamp in the window title. This is also slow and something I don't want to be bothered with. I also don't want to be bothered with window management, but to see things side by side I have to rearrange windows all the time.
• I have to close the oldes traces to not drown in tracy windows. If I confuse one trace for another, I might lose a trace I actually wanted to look at.
• I'd also want to use the compare feature, but saving the file, selecting a name, and then selecting the right file to open in the compare file dialog is just slower than having two windows open and opening statistics for the zones I am interested in.

The requested features would improve on all of these issues:

• the new ui element shows the order of the traces clearly. I can just select the latest one without double checking.
• I can compare two traces without having to select a file name, and going through two file dialogs.
• I don't need to have multiple windows open and don't need to bother with window management.

I am fully aware that these are not very pressing issues: I can continue to use my current workflow and it'll be fine. But I think this might be a substantial productivity win for a lot of people.

[wolfpld]

This has been on my mind for some time now.

[simonvanbernem]

Thats encouraging to hear :D.

I guess having multiple traces open at once opens up even more possiblities, like maybe auto-detecting significant changes and presenting them to the user, having multiple synchornized timelines and things like this, but I didn't want to drown you in feature requests.

Although brainstorming what would be possible could be interesting. Can't think of much more off the top of my head, but there's gotta be a lot more.

[aolo2]

I'm +1-ing this request. Moreover, I've written almost exactly the same thing to @wolfpld some time ago, which I find pretty amusing. Relevant part of the email:

My use case consists of making changes and rerunning the program very often (sometimes tens of times per hour). Saving each trace and using the compare function is kind of overkill, so I just screenshot the relevant statistic window :) Also pressing wifi button -> Discard -> "Reconnect" feels like something I shouldn't have to be doing.

To make this comment at least somewhat useful, might I suggest you try the screenshot method, @simonvanbernem? :-)

[simonvanbernem]

@aolo2 thanks for the suggestion :D. My current workflow is pretty ok so I don't think I need to take the screenshot-route. I just wish it was better. I also find myself comparing different parts with varying resolution, so I don't think screenshots are the best solution for me.

[liquefact]

I have a similar use-case. I'm running multiple instances of the same application (simulation server) which are synchronized through shared memory. Usually my workflow is;

• Run 4 instances of the app
• Attach one Tracy window to each running app (using client discovery)
• Scale each tracy windows to be roughly 1/4 x screen height and 1x screen width and place them starting from top of the screen to bottom.
• Start profiling
• Find problematic frames, bring the same frame in each tracy window and try to set the same zoom level to be able to see synchronization points between apps.
• Fix code, repeat.

So, I'd very much like to automate this process by treating all open sessions as a group.

1. Opening up multiple sessions in the same tracy window, each session (tracy server connection to a client) going into a pane (or widget maybe?).
2. Locking the zoom/frame settings for each session so that whenever I change these for one session, it applies to others as well. Like, for one session, when I go to Frame N, all panes go to the same frame N and zoom (view span) settings are set the same. Basically all pane's view spans are the same.
3. Making Resume / Pause buttons apply to all open sessions.

When I profile the apps, I repeat the above steps hundreds of time and it'll be a productivity boost for me if we can automate the above workflow. Any suggestion is very welcome.

[simonvanbernem]

I wanted to ask what the status on this issue is. It is the single biggest usability gripe I have with Tracy and having it improved would be great!

[wolfpld]

Sorry, but not much has happened with it.

[simonvanbernem]

Are you planning to work on it in the near future, or is this a task for the long-term backlog?

Also, is there a roadmap for Tracy, or is the work on it more informal? Would be cool to see what is being worked on, but since I assume you are spending your free time on it, I understand if you don't want to add bureaucracy to the process.

[wolfpld]

There is no roadmap, as this is basically a hobby project.

Would be cool to see what is being worked on

https://mastodon.gamedev.place/@wolfpld/110051360673082727

[sifangli-labs]

Hi, I am new to Tracy and also interested in this feature - as far as I can see this is not going to be there soon.
I think I can easily go with embedding the tracy (capture) server into my apps. The readme says I can do that in the same way as the client side. Can you provide details of how to embed the 'capture' part of server into diff applications and running them at the same time? I guess what gets me is that capture.cpp has a main function already - I guess I can modify it myself - just wonder what is the official way for embedding it on my apps.
Thanks.

BTW, would this make the overhead unbearable? Would this end up as Tracy profiling itself (the capture part, anyway)?