Spinner with indeterminate:true causes very high CPU load

[ubruhin]

This code:

import { Spinner } from "std-widgets.slint";

export component AppWindow inherits Window {
    Spinner {
        indeterminate: true;
    }
}

Causes very high CPU load. I observed the following values:

• VSCode Integrated preview: 75-100%
• Standalone preview: ~15%
• Compiled application (C++, Qt backend): ~10%

These values get worse with a more complex UI (currently 50% for my compiled application).

---

Slint 1.8.0 Style cosmic-dark Linux x64 i7-6700K

[tronical]

Are you using X11 by chance?

[ubruhin]

Ah good point I forgot to mention: Yes, I'm using X11. I might be able to check it with Wayland soon.

[tronical]

It's possible that this is related to #5050, but it's also possible that in addition rendering performance is poor for you. Could you elaborate on the choice of renderer/backend of your application? I assume that you have i915-style GL drivers?

[ubruhin]

Could you elaborate on the choice of renderer/backend of your application?

I need the Qt backend because my application already heavily depends on Qt (see #6352).

I assume that you have i915-style GL drivers?

It's the NVIDIA driver, though I suspect that's not relevant for the Qt backend(?).

[tronical]

Ah yes, indeed, then most likely this isn’t due to frame throttling (I think Qt falls back to a timer that matches the reported refresh rate). Instead, my guess is that the software rendering with overdraw and no partial updates eats away CPU :-(

Should this become an enhancement ticket for partial rendering with QPainter, @ogoffart ?

[ogoffart]

The problem is even worse with VSCode Integrated preview (75%-100% CPU) So I think this should be an enhancement for partial rendering with every renderer.

[ubruhin]

Just tested with Wayland on a different system (AMD Ryzen 7 5700U, integrated graphics). Even worse:

So it's not related to X11.

[tronical]

The problem is even worse with VSCode Integrated preview (75%-100% CPU) So I think this should be an enhancement for partial rendering with every renderer.

I'm uncertain that it's possible to implement partial rendering with WebGL rendering. At least I haven't found anything in the spec, and I don't see any support for the buffer age extension.

My guess is that the fragment shader intense approach of FemtoVG performs just a lot worse than skia in this case.

What should be the acceptance criteria for this issue?

[ogoffart]

What exactly do you mean by "VSCode Integrated preview" and "Standalone preview" Do I understand correctly that the former is the one in a VSCode tab (femtovg+wasm) when the later is the preview in its own window (skia+winit)

But maybe the problem is not partial rendering. It could be something else. What about the browser if you go to https://docs.slint.dev/1.8.0/demos/gallery/ (it takes about 50% for me with firefox) does the CPU get better if you make the preview tab as small as possible?

[ubruhin]

What exactly do you mean by "VSCode Integrated preview" and "Standalone preview" Do I understand correctly that the former is the one in a VSCode tab (femtovg+wasm) when the later is the preview in its own window (skia+winit)

Yes, correct.

But maybe the problem is not partial rendering. It could be something else.

I'm not sure either. The spinner is the only element in the window, so there's nothing else to render except the spinner.

What about the browser if you go to https://docs.slint.dev/1.8.0/demos/gallery/ (it takes about 50% for me with firefox)

Around 30% for me (firefox). Considering the much more complex UI than just a spinner, that's way better.

does the CPU get better if you make the preview tab as small as possible?

Huh that's indeed interesting - when I resize the VSCode preview tab to just the spinner size, I get around 100% CPU. If I resize the tab to fill a large part of the screen, it goes up to >900% CPU :hushed:

[ogoffart]

Really strange that this give so little CPU in a browser, but more CPU in vscode. Note that vscode is based on electron which is based on chromium. Maybe you can try with chrome or chromium? But chromium and firefox use about the same amount of CPU for me when showing the gallery. But the integrated preview indeed takes about 1000% CPU if i make the window big. I can reproduce that.

@tronical Not sure in what category to place this issue. Is it wasm? is it editor integration? is it preview is it femtovg?