Basic real time plotting

[saturn77]

I am a long time real time controls engineer, often using FPGA + SoC in conjunction with telemetry link to a Qt GUI where I have typically used PyQtGraph for real time plotting and in some cases C++.

I like the sixtyfps project, particularly as I have been writing applications in Rust for the past three years and really like its many advantages. I really like the native integration of Rust into SixtyFPS.

So I have a new project, in which I need to do real time plotting. Any suggestions on the applicability of doing that with SixtyFPS? I would need to plot say 2 variables at any one time, and it would be nice to expand or contract the "scene" like one can do in PyQtGraph. If anyone is working on something like this, I would be happy to help out or test. Thanks. James

[tronical]

Hi @saturn77,

Generally this is a use-case that we'd like to support - it has come up a few times in the past. There's no out-of-the-box solution right now, but I'm a curious about your use-case to see what the best path forward is. So I have a few questions :-)

Is the amount of data and the type of visualisation well suited for generating the graphical representation on the CPU, or is this something that envision requiring a GPU?

If the former is acceptable, then perhaps there's a rust crate out there that can generate suitable graphics (maybe https://lib.rs/keywords/plotting has something?) and all we need to provide is a way to allow doing the controls and feeding the generated image into SixtyFPS, as an image. We have sixtyfps::Image::load_from_path and could have a sixtyfps::Image::load_from_argb function next to it perhaps.

If you require rendering on the GPU, then it depends whether this can be done with existing path rendering primitives or whether it requires custom shaders.

If you can transform your data into meaningful path curves then we could perhaps either offer an imperative "Canvas" style API ("here's a canvas to paint on, it's an FBO") or the existing Path primitives with a bit more work. The iot-dashboard example tries the latter approach.

If you're best off somehow feeding your data into a texture (or some other kind of buffer) and do the fragment generation entirely using custom shaders, then we need to provide hooks for that - even if they're initially maybe OpenGL specific.

So I'm curious, are there already good supporting plotting crates in the Rust ecosystem that we could connect with somehow?

[DaMilyutin]

@tronical , I want to do similar thing from C++ side. I mean fill Image's SharedPixelBuffer and send it to Image.
However, there is no big choice of constructors in Image C++ API.
Can you clarify how can I do it?

P.S. What is least painful way to switch from sixtyfps to slint?

[tronical]

The corresponding constructors (or factory functions) need to be added to slint::Image in C++. I think it would be similar to the Rust from_foo functions but maybe just take a span of bytes. There might not be a perfect data type, so it’ll likely be more low level.

P.S.: I made two migrantions, one in Rust and one in C++ and it was mostly search and replace. The biggest changes apart from that were in the Rust model API and the CMake API. Let us know if there is anything missing in the migration guides :)

[DaMilyutin]

@tronical, should I create issue for this augmented interface of Image?

Can you clarify how ownership goes bettween Rust/C++ boundary?
Can I allocate something in C++ and pass it to Rust like (Ex. std::vector<char> or raw pointer to allocated array of char, or unique_ptr<char[]>)?
Or must I first create Rust data owner (allocated on Rust's side) wrapped by C++ handle object (ex. SharedBuffer) and access it on C++ side?

[ogoffart]

There is already an issue for it: #616

[ogoffart]

Can you clarify how ownership goes bettween Rust/C++ boundary?

Everything that is allocated by the rust allocator must be freed by the rust allocator. And similarily for the C++ allocator.
We have SharedVector that can be shared between rust and C++ because it only use the rust allocator.
The SharedPixelBuffer Rust type contains a SharedVector, so that's what we need in our binary interface.

[saturn77]

That is very good news. Plotters does indeed seem to be a good library, and having it connected to sixtyfps would allow for a host of applications . . .

[saturn77]

Just a quick question/comment here on the merge request #392 for the code that you have with plotters.rs - it look like wasm bindgen attribute is being used, so I take it this example will run in the browser, that is very cool. I think I saw somewhere that people were saying sixty is for desktop and embedded, but I don't agree with that with respect to wasm tools. After all, that is how Yew and egui also do their webviews . . .

[tronical]

In principle yes, this should work in the browser, too. In practice plotters panics when trying to measure text for axis text as font-kit won’t report any fonts (or something like that). Nothing insurmountable though.

[saturn77]

I see that #392 has been merged into master now, thank you for all the hard work and various commits to make it happen. I will use the example and port to my new design.

[DaMilyutin]

I'm interested in plotting, too. Not real time though.
But I'd probably plot big arrays of data and I need to analyse those in depth.
So I need pan/zoom and to render it fast.
I'm curious about having something similar in functionality to QCustomPlot.
I wonder if this kind of widget is implementable via plotters?