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
8Looks 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.
Maybe as an extension of the existing plot configuration message?
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.
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.
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.
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.
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.
BuildSpectrogramreadsm_view.GetViewData().plotHeightfrom inside thetd.Queuelambda (TracyTimelineItemPlot.cpp:280-281). It is the only queued Preprocess lambda in the profiler that touchesm_view; every other one works offctx+ worker data. Not academic:plotHeightis 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: captureconst auto plotHeight = m_view.GetViewData().plotHeight;on the main thread beforetd.Queue(Preprocess already does main-thread work at line 143 for exactly this kind of thing). Should fix before merge.2.
fill/showStepsoptions go dead silently. Spectrogram mode skips fill entirely (and explicitly in the rightEnd branch,TracyView_Plots.cpp:204) and never honorsshowSteps. 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 > 1both 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 inmanual/tracy.texwould close it.4. Nit: stray double blank line at
TracyTimelineDraw.hpp:110(the+on an empty line after};).