Performance improvement for the Plotter example

[nanopink]

newnew.mp4

[ogoffart]

Great achievement.

Could you explain what you did to get there and why it helps?
I'm concerned that using set_render_notifier for this is not as portable as the first method, and also a bit more complicated for an example. I'd like to understand why this is faster though.

[ogoffart]

Does that mean that you will force a refresh all the time even if nothing changed?

[nanopink]

Yes, no choice there is no resize event in slint and using the texture dimensions requires this
Because Slint also uses the request_redraw so we can't only re-render when we need to because its constantly called anyway by for example the slider thumb animation, and other factors

Even if you were to add for example a callback on width and height change on image it would spam it because the resizing is not instantaneous

As seen in this earlier issue I recorded, the slider spams render window, because the render loop given is tied to the UI rendering, so they both end up inefficient, its a design flaw

Note that on my main project I stopped using Slint for this exact specific issue ironically

On this video we do not request a redraw every frame so the texture is not automatically updated
And as you can see the slider's position change enforce redraw calls multiple times, rather than compute its final position before rendering, this is likely tied with an issue with Rectangle where when an image is inserted inside a rectangle, it affects the parent rectangle's size

rec.mp4

[ogoffart]

Is that not the default? why do you change this?

[nanopink]

This is the default which you use, but this specification wasn't there so my formatter used the wrong format
It'll prevent CI reformatting for future contributors who do not have this option in their vscode settings

[ogoffart]

This rotation shouldn't be needed. Instead the we should fix the sliderto be in the right direction.
(I remember some discussion about that in #4705 (comment) )

[nanopink]

I agree, technically it should be orientation up, down, right or left, or maybe just vertical / horizontal but where min and max are replaced by start and end and it can start at 10 and end at zero
Although ideally in the future a slider could have 2 ends to select a range, this is something else to consider

[nanopink]

Before: When we drag the slider or the graph's view, a cascade of render calls hammers the render function non-stop, causing intense lag spikes

Now: When the window is ready to render, it verifies if the variables of the plot changed, in which case only then it renders

Additionally previously the graph used to be hardcoded at a resolution of 640x480 so I made it dynamic

The code is expected to work everywhere as we haven't added anything new and we're just appending to Slint's inner workings

These changes significantly improve performance and responsiveness, a smoother experience makes the plotter example feel more polished and professional, which helps create a better first impression for new users exploring Slint

In the latest commit I removed the styling changes (dark mode) to reduce the lines count even further and verified it works in WebAssembly

[tronical]

Perhaps I’m missing something. Why do you think the old code re-rendered the plot every frame instead of on-demand?

[tronical]

Generally speaking, one of the objectives of this example is to demonstrate how to render such a graphic lazily using a binding that’s re-evaluated only when a parameter changes. That happening automatically is IMO very convenient and a good pattern that’s worth preserving.

[tronical]

The inability to specify the width and height of the surrounding element for the render function though is an annoying bug (in Slint, not the example). So hardcoding the size sucks, that I agree with.

[nanopink]

Perhaps I’m missing something. Why do you think the old code re-rendered the plot every frame instead of on-demand?

image.source used amplitude-slider.value as variable
Which means if the slider ticks 70 different values while you drag, it will attempt to render 70 times in that short time frame, the render_plot function couldn't provide that fast, so it overloads, same thing with dragging, which is why its "stable" only if you drag really slowly, so the tick count is low
It doesn't render every frame but instead renders the same frame multiple times

[ogoffart]

Which means if the slider ticks 70 different values while you drag, it will attempt to render 70 times in that short time frame

I don't think that's right.
The function should only be called once per frame when rendering.

although there is maybe a bug that caused the plot to be rendered on mouse event, and there would be many mouse event being handled preventing the frame to be drawn.

Possibly related to #9038
and #749

IMHO we should probably compress/merge events so that we process only one mouse move event per frame

[nanopink]

It was assumed by experience with other renderers I did not test anything, I just saw and estimated then fixed, it might be a completely different issue
If you aren't pleased with the changes feel free to close the pull request, in my case I just wanted to use it to quickly setup a real time graph visual for the AI that I'm working on and the way it was originally was unusable