dimtpap
Graphs perfectly smooth only while moving mouse.
First off, very interesting application! I hope it will get option to easily change sample rate a latency/quantum so that meta commands through terminal is not needed.
The issue I noticed is that the graphs are only updated smoothly when I move my mouse cursor. I am using the Flatpak version under GNOME 45 (Wayland) and I have made a short video demonstrating the issue.
https://www.youtube.com/watch?v=onk9GPrMPpg
I just stumbled across this, what an outstanding application, thank you so much! I immediately intended to package it for openSUSE but it's already been included in the Factory, meaning it's available 'out of the box' for all OpenSUSE users. I just pushed the update to 1.5.1 to try and contribute something.
I especially like the live profiler view, this is a tool that's going to be incredibly useful for pushing our systems to extreme low-latency configurations. Can't thank you enough, this will save me so much trouble!
See #3 for why it's happening. I guess a toggle would be desirable
Perhaps, similar to the box allowing us to select the number of records to show, we could have an update rate we could set? Then we could have something that would not necessarily overload a person's PC, but if they have a particularly powerful PC, they could set a very short update timer? Just a thought.
Anyway, for now I'll just keep moving the mouse :D thanks again, what a fantastic application!
Perhaps ... we could have an update rate we could set? for now I'll just keep moving the mouse :D
I noticed when using this technique yesterday, that this seems not only to be a case of the data being drawn to screen more often, but actually sampling data more often. It's not just visually smoother when moving the mouse, the values are more accurate.
This doesn't seem too bad from a very 'zoomed out' view like this (25000 samples), but when you are zoomed in, the slow sample rate means that spikes can be lost and masked from analysis. Not a bad thing, we still get a perfectly accurate view, but it should be considered that the data is effectively filtered to more frequent events.
I wonder if it might be possible not only to modify (increase) the display update rate, but also, to modify (increase) the sample rate? Ultimately it would be great to accumulate timing data for everything, but I can understand how that might introduce more problems than it solves, by being a performance hog, so, periodic sampling is done instead(?). Forgive me if this is a dumb question, I haven't even begun to look at coppwr's code yet, it's just a magic black box to me :)
The sampling should be completely independent of the graphics. Every sample that PipeWire sends gets displayed. If you're viewing the graph of a video driver such as a screen or coppwr window capture then you may notice more samples because PipeWire sends info about the frames created from moving the mouse
The sampling should be completely independent of the graphics
Hah. Well, I thought, "surely moving the mouse over my display can't be causing all these extra peaks", and analysed kernel timings and stuff to make sure it wasn't just a busted driver, and concluded that it must be sampling... but, I guess my intuition was right, and it really was more peaks!
I think this might be unrelated and I would prefer not to hijack, so I'll bring this up again elsewhere. Apologies for the interruption here!