Open mcourteaux opened 1 month ago
Zooming reveals that the data is actually completely bogus. See the video:
Yes, this looks to be completely broken. Can you share a trace with these plots?
I had to zip again, to make Github accept it.
I can reproduce the issue with your trace. It's certainly something interesting.
Without looking at the data, this looks like an unsorted plot, as you can see values going forward and backward in the screen below, and the glitching you see when zooming is a result of a binary search that can't work properly.
Tracy handles out-of-order plot points by design, this is a very old functionality and there were no problems with it before. I am not able to reproduce your issue with the test/
application that generates millions of plot points from two threads, which results in a lot of resynchronization. The glitchy plots in your trace are in the 50-500 plot points range, and I'd expect there's no need to synchronize anything at all, with such low numbers.
The only recent thing that may affect this that comes to mind is replacement of the parallel STL with the ppqsort library.
Is this something we can test by going back to before ppqsort got introduced with the same trace file? I'm assuming the ppqsort stuff happens in the Tracy UI, but perhaps the trace file format changed since then? If it's not, I can attempt my first-ever git-bisect. 😄
PPQSort was added in 1c1faeff2. The trace format has not changed. Opening the existing trace will not result in any changes, you would have to redo the trace and see what comes out.
Zooming reveals that the data is actually completely bogus. See the video: Wayfarer_2024-10-08_114209.webm
Also note this double-rendering in the blue and yellow plot:
I'm currently on e6eb9899