Program takes a very long time to start (Linux, Wayland, Hyprland)

[progzone122]

Problem

It takes a very long time to start the program!
This should not be the case. Is this a bug or am I doing something wrong?
This happens in any project.
Example project: https://github.com/progzone122/micropad/tree/main/micropad_engine

2024-06-03.13-51-53.mp4

My PC info

[hunger]

Works-for-me(TM), which unfortunately also means I am not able to help very much:-(

Can you run a profiler and check where it spends all the time? I guess it is waiting for something to time out before falling back to something that works.

Hypraland is that wayland bling-thing, isn't it? I had some programs behave strangely on wayland before, maybe this is related. Check your environment and remove DISPLAY from it before starting the program. Then try without WAYLAND_DISPLAY and see whether either makes a difference.

[tronical]

There are a couple of other things that you could try, which might help us narrow it down:

1. Does it get better if you run with SLINT_BACKEND=winit-software? (not a solution, just a way of diagnosing)
2. Could you replace slint = "1.6.0" in your Cargo.toml with slint = { version = "1.6.0", features = ["renderer-skia"] } and see if that changes anything? (might be an issue with shader compilation in femtovg)
3. Finally, with (2) applied, could you try setting SLINT_BACKEND=winit-skia-software and see if that helps?

Thanks :)

[progzone122]

Works-for-me(TM), which unfortunately also means I am not able to help very much:-(

Can you run a profiler and check where it spends all the time? I guess it is waiting for something to time out before falling back to something that works.

Hypraland is that wayland bling-thing, isn't it? I had some programs behave strangely on wayland before, maybe this is related. Check your environment and remove DISPLAY from it before starting the program. Then try without WAYLAND_DISPLAY and see whether either makes a difference.

I generated perf.data (Renamed it to perf.txt). Flamegraph doesn't work for me for some reason, so here goes

perf.txt

[progzone122]

Works-for-me(TM), which unfortunately also means I am not able to help very much:-(

Can you run a profiler and check where it spends all the time? I guess it is waiting for something to time out before falling back to something that works.

Hypraland is that wayland bling-thing, isn't it? I had some programs behave strangely on wayland before, maybe this is related. Check your environment and remove DISPLAY from it before starting the program. Then try without WAYLAND_DISPLAY and see whether either makes a difference.

When DISPLAY is removed, everything stays the same, but when I remove WAYLAND_DISPLAY it starts up much faster.

2024-06-03.19-57-46.mp4

[progzone122]

There are a couple of other things that you could try, which might help us narrow it down:

1. Does it get better if you run with `SLINT_BACKEND=winit-software`? (not a solution, just a way of diagnosing)

2. Could you replace `slint = "1.6.0"` in your `Cargo.toml` with `slint = { version = "1.6.0", features = ["renderer-skia"] }` and see if that changes anything? (might be an issue with shader compilation in femtovg)

3. Finally, with (2) applied, could you try setting `SLINT_BACKEND=winit-skia-software` and see if that helps?

Thanks :)

1. Starts up quickly, but the window scales poorly

2024-06-03.20-10-49.mp4

2. It still takes a long time to start up
3. A little faster, but still very long

2024-06-03.20-22-43.mp4

[tronical]

Fascinating. Thanks for the new update. Could you try SLINT_BACKEND=winit while also setting WAYLAND_DEBUG=1 ? It should still be slow, but there should be a lot of output and perhaps this would show if a particular round trip to the compositor takes a long time.

But from this my money is on the GL driver being either slow to allocate or negotiate dri buffers - as opposed to the shm buffers used with software. Although Skia software should also be much faster then.

[progzone122]

Fascinating. Thanks for the new update. Could you try SLINT_BACKEND=winit while also setting WAYLAND_DEBUG=1 ? It should still be slow, but there should be a lot of output and perhaps this would show if a particular round trip to the compositor takes a long time.

But from this my money is on the GL driver being either slow to allocate or negotiate dri buffers - as opposed to the shm buffers used with software. Although Skia software should also be much faster then.

No, starts up quite quickly, the window scales normally

Debug info: debug1.txt

2024-06-03.21-06-06.mp4

[ogoffart]

I think this might not be related to Slint at all.
The main.rs does a bunch of stuff with serial port and stuff before showing the UI.
You can try to add a bunch of println!() at the beginning and see what is taking so long.
You shouldn't call anything that blocks the main thread. You should use another thread or some async functions

[progzone122]

I think this might not be related to Slint at all. The main.rs does a bunch of stuff with serial port and stuff before showing the UI. You can try to add a bunch of println!() at the beginning and see what is taking so long. You shouldn't call anything that blocks the main thread. You should use another thread or some async functions

No, even if I comment out all my logic, the program still starts after 15 seconds.

[progzone122]

I think this might not be related to Slint at all. The main.rs does a bunch of stuff with serial port and stuff before showing the UI. You can try to add a bunch of println!() at the beginning and see what is taking so long. You shouldn't call anything that blocks the main thread. You should use another thread or some async functions

Although I agree with you that you should put in a separate thread or use asynchronous functions.

[progzone122]

I think this might not be related to Slint at all. The main.rs does a bunch of stuff with serial port and stuff before showing the UI. You can try to add a bunch of println!() at the beginning and see what is taking so long. You shouldn't call anything that blocks the main thread. You should use another thread or some async functions

No, even if I comment out all my logic, the program still starts after 15 seconds.

2024-06-04.01-22-08.mp4

[tronical]

Works-for-me(TM), which unfortunately also means I am not able to help very much:-(
Can you run a profiler and check where it spends all the time? I guess it is waiting for something to time out before falling back to something that works.
Hypraland is that wayland bling-thing, isn't it? I had some programs behave strangely on wayland before, maybe this is related. Check your environment and remove DISPLAY from it before starting the program. Then try without WAYLAND_DISPLAY and see whether either makes a difference.

I generated perf.data (Renamed it to perf.txt). Flamegraph doesn't work for me for some reason, so here goes

perf.txt

The perf data as well as the wayland output suggest that the application is waiting for Hyprland to do something. The Slint side and your application is idle. Do you see CPU usage in Hyprland during this period of inactivity?

[ogoffart]

Should also try to compare with one of the pure winit example. from the winit repository.

[progzone122]

After experimenting a bit, I discovered something interesting:
If you run a program several times within a short period of time, after a while everything will start up instantly
But after restarting the computer, it is again required to run 1-3 times with such a long delay.

[lmaxyz]

There is an interesting line in winit code. I met it when I was doing my fork and forgot to remove this line, and my app infinitelly waited for configuration.
In your case maybe compositor or something else does something slowly, and winit waits for configuration too long because of it.