You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Quickplot as it is (version 1.0.1rc), is pretty much dead and broken.
The current quickplot package release in Debian (Debian GNU/Linux 12) (bookworm), debian package version 1.0.1~rc-1+b4, is not usable; well at least on my computer with the KDE plasma desktop using the Wayland display.
X11 is dying and being replaced by Wayland. If we can use Wayland memory mappings to 2D draw, quickplot could be a lot faster than with X11 drawing. Will we use the widget sets drawing wrapper API, or get the Wayland memory mapping to draw to? I'm not sure which.
See Issue Incompatible with current libsndfile1 #3. Quickplot is not compatible with the current libsndfile. libsndfile has always been a little broken and the developer is not responsive to fixes that I have requested in the past. It's likely I'll just drop it's use. Looking at Issue Incompatible with current libsndfile1 #3 I see progress, so I'm not sure what I'll do.
It's time for another total rewrite of quickplot. That would be the 5th rewrite;
1998 Athena Widgets X11 GUI (graphical user interface) program
2003 Qt widgets
2004 GTK+ GTKmm
2011 GTK+ 3.0 without GTKmm
The near future. 2024. Have not decided yet: either Qt version 6 or GTK version 4
The big question I see now: Does quickplot really need to allocate a buffer for each channels data? I can't see zooming working quickly without that. Is process memory that cheap and series data that relatively small? I think so. And: if yes than why not make a native file format that can be directly memory mapped into the quickplot process as this required buffer? And yes of course the native file format would just be optional. I also need to see if there is a common file header format that exists, for this kind of binary data. So ya; thinking out loud ...
I need to study the relative memory size limits; that is what is a large data file (and also what is a common size) and compare to a large process memory allocation (and what is a common size). Plotting a million data points is not very large on today's computers. Looks like I have the most data intensive case that I need with plotting SDR (software defined radio) Q/I data.
Can the quickplot software also be a quickscope? I've been trying to do that for years. quickplot with just be a "frame grab" from quickscope. The big problem is that the "main" buffer for a 2D scope is very different from static 2D plotter. The 2D scope does not need to keep the channel series data as it comes into the process and the static 2D plotter does (so I think).
Do I want to try 3D displays? Maybe just 1D series data in 3D display, looks like spaghetti? I don't want to write a paraview?
Quickplot as it is (version 1.0.1rc), is pretty much dead and broken.
It's time for another total rewrite of quickplot. That would be the 5th rewrite;
The big question I see now: Does quickplot really need to allocate a buffer for each channels data? I can't see zooming working quickly without that. Is process memory that cheap and series data that relatively small? I think so. And: if yes than why not make a native file format that can be directly memory mapped into the quickplot process as this required buffer? And yes of course the native file format would just be optional. I also need to see if there is a common file header format that exists, for this kind of binary data. So ya; thinking out loud ...
I need to study the relative memory size limits; that is what is a large data file (and also what is a common size) and compare to a large process memory allocation (and what is a common size). Plotting a million data points is not very large on today's computers. Looks like I have the most data intensive case that I need with plotting SDR (software defined radio) Q/I data.
Can the quickplot software also be a quickscope? I've been trying to do that for years. quickplot with just be a "frame grab" from quickscope. The big problem is that the "main" buffer for a 2D scope is very different from static 2D plotter. The 2D scope does not need to keep the channel series data as it comes into the process and the static 2D plotter does (so I think).
Do I want to try 3D displays? Maybe just 1D series data in 3D display, looks like spaghetti? I don't want to write a paraview?
References:
https://github.com/lanceman2/quickplot
https://github.com/lanceman2/quickscope
https://github.com/lanceman2/quickstream