#1471

Draw dense plots as spectrograms

Draftany1wants to merge intofrom

I wanted to get a better idea of the distribution, so I had Claude implement this idea for me.

If the plot is too dense for all the individual points to be displayed on separate pixel columns, it'll be rendered as a spectrogram instead.

Would you be interested in this if I develop it further?

Activity

8
wolfpld1mo ago

Looks interesting. What would be the solution for "dense islands + sparse points" scenario? The second issue below rises a related problem.


1. Cross-thread View access — only genuine defect. BuildSpectrogram reads m_view.GetViewData().plotHeight from inside the td.Queue lambda (TracyTimelineItemPlot.cpp:280-281). It is the only queued Preprocess lambda in the profiler that touches m_view; every other one works off ctx + worker data. Not academic: plotHeight is user-editable via the Options slider (written on the main thread, TracyView_Options.cpp:682,935) while these tasks run. Torn read of an aligned int is physically implausible and the value converges, so it won't crash — but it breaks the file's established confinement, and it's trivially avoidable: capture const auto plotHeight = m_view.GetViewData().plotHeight; on the main thread before td.Queue (Preprocess already does main-thread work at line 143 for exactly this kind of thing). Should fix before merge.

2. fill/showSteps options go dead silently. Spectrogram mode skips fill entirely (and explicitly in the rightEnd branch, TracyView_Plots.cpp:204) and never honors showSteps. Users toggling those in Options see no effect while zoomed dense.

3. Manual overstates accuracy under sampling. The added paragraph promises "the number of values in the column, their range"; with skip > 1 both are estimates and the column range can under-report extremes. The UI itself is honest ("Estimated number of values:", TracyView_Plots.cpp:374). One clause in manual/tracy.tex would close it.

4. Nit: stray double blank line at TracyTimelineDraw.hpp:110 (the + on an empty line after };).

any11mo ago

Looks interesting. What would be the solution for "dense islands + sparse points" scenario? The second issue below rises a related problem.

I guess they could be bridged, but that might give the false impression that you have data points for them. Switching to a full "regular" plot for those sections would show the individual points, but it could get somewhat crowded. The simplest solution is probably to have an option turn this feature on/off.

wolfpld1mo ago

Maybe as an extension of the existing plot configuration message?

any11mo ago

Well, yes, the nature of the data is usually known at the source, but it might also be good to be able to toggle this globally in the config menu.

YaLTeR15d ago

I just randomly came across this, and from looking at the screenshots it looks cool, but I'm afraid as shown, it is too easy to miss the extreme points. Say you're looking at the audio sync error on your example. You're probably interested in the outlier extreme values, but as is they are tiny 1 px dots that don't stand out at all.

wolfpld15d ago

fwiw the way plot drawing currently works with large amount of items is random sampling (well, some stable interval). This is why you will see shimmer and there isn't really a way to find what the extreme data values are.

any115d ago

Well, the graph's range tells you what the extreme values are. It might be useful to have a "glow" around each pixel.

This pull request is a draft

Merging is unavailable until it is marked ready for review.