@rickbrew mentioned on twitter he'd added tracing to Paint.NET using the tracing format used by Chrome (and Brave and the new Microsoft Edge) dev tools.
It would be good to add this as and output/conversion format for dotnet-trace as either browsers UI are highly developed and well used and understood especially by webdevs and it can happily open and analyse file in that format from other sources.
chrome://tracing can open gzipped files (.json.gz) where as dev tools only understands them as raw .json. Dev tools is a little easier to use (and probably most familiar) whereas tracing is a dedicated UI for looking at larger traces. So it may be useful to provide an additional .gz output option, but not have it as the default.
The json is also a format speedscope understands
/cc @migueldeicaza @lucasmeijer
I just took a look at the file format, and it seems remarkably similar to the speedscope format (or I guess speedscope seems similar to it 馃槢). If I find some time, I'll take a look at what what amount of work it would take to write a converter.
Sneak preview:

Needs a little polish, but it went together pretty quickly. Won't open in edge://tracing, but opens in devTools (haven't tried Chrome yet). Very cool timeline view of stacked icicle graphs per thread!
Wow that was fast! 馃槃
I was intrigued by the idea 馃槃! Current version is hacked together building off @adamsitnik's work for the speedscope format. I need to figure out where this code will live after I polish it. I did a similar converter that lit up cachegrind using the callgrind.* format, which will hopefully make it in as well.
@josalem awesome! Can't wait to use it!
I need to figure out where this code will live after I polish it
perhaps it could live in TraceEvent as the SpeedSopeExporter?
@josalem Did you manage to find a place for the code? I'm doing a talk on the new diagnostics tooling soon and opening up the trace in Chrome/Edge Developer Tools would make for a pretty awesome demo IMHO ;).
@jmezach, I haven't had a chance to polish it yet. I will most likely be putting it next to the SpeedScopeExporter in TraceEvent over in Microsoft/PerfView. I'll hopefully get a chance in the next couple weeks to polish it. Give me a sec and I'll push my hacked version of dotnet-trace that you can use to either convert a current trace or collect a new one. It _is_ a hack, so it has errors in the data and whatnot, but will generate that fun view in Edge/Chrome. Note that the file size for this format blows up. I'll hopefully fix that 馃槄.
@josalem any progress on this? I am demoing dotnet diagnostics tools at a conference next week and I would love to show it too ;)
@adamsitnik here's a link to my hack branch: https://github.com/josalem/diagnostics/blob/bd21c0d4efd2d2ea1c5b361fdfa015034cfd74ce/src/Tools/dotnet-trace/TraceFileFormatConverter.cs#L102-L520.
I'm intending to take some time to polish this, but I'm not sure when that will be. The few outstanding issues with it seem to be
I'll probably put this code in Microsoft/PerfView, but I had it in dotnet/diagnostics for hacking
huge file size
I just wanted to let you know that last week I've meet Martin Cervinka, the author of https://gitlab.com/virtex/tracing who said that this problem can be solved by zipping the trace file and that Chrome is capable of opening zipped trace files.
@adamsitnik thank you for introducing me to dotnet-trace and point me here.
@josalem
- TraceEvent gives us data in ms.
I know it's a bit general question. but I'm very surprised that dotnet-trace TraceEvent has a timestamp resolution only in milliseconds. Is it true?
Most helpful comment
Sneak preview:

Needs a little polish, but it went together pretty quickly. Won't open in
edge://tracing, but opens in devTools (haven't tried Chrome yet). Very cool timeline view of stacked icicle graphs per thread!