Slow shell start on niri #8236
Comments
|
I don't see what kitty can do here. If niri claims to support fractional scale and preferred integer scale but then doesn't send those events for scale 1 surfaces then there is no way for kitty to know when niri is finished configuring the surface. I dont know what wayland backend niri uses but every other compositor that claims to support these protocols sends these events for scale 1 surfaces. And the wayland protocol has no other way to know when the compositor is done with initial set up for a window. |
|
And just for the record, here is the debug rendering log for niri: We can see it sends a fractional scale of 1 before configure and then nothing after. Here kitty doesnt wait because even though the fractional scale was sent before configure and not after, the preferred buffer integer scale of 3 is sent before the configure and so kitty gets a signal that the window is fully setup. The only "fix" I can see here is to detect niri and try to workaround it or detect hyprland and try to workaround it. It would be a lot more helpful if niri simply sent another fractional scale event after the configure event. Even if the scale is unchanged it serves as a signal that the setup is done and follows the behavior of all other compositors. Or alternatively sends a preferred integer scale event even though 1 is the default value. |
|
Hey, so yeah, we don't send preferred buffer scale = 1 (or preferred buffer transform = Normal for that matter) because it's the default as per the protocol. I don't see why Kitty needs to wait for anything in this case? If the compositor doesn't send all necessary events by the initial configure, that sounds like a compositor problem to me? As in, if the compositor wanted scale != 1 then it should send it before the initial configure, and if it left scale at default then that's what it should get. |
|
It needs to wait because all other compositors send fractional scale after configure. Which leads to extra resize events which can cause software running inside kitty, not ready to receive SIGWNCH during startup to crash. So if niri simply sends either a preferred buffer scale before configure unconditionally even when the scale is 1 or it sends fractional scale after configure unconditionally even if it is one, kitty will work fine with it. And yes, you are correct that this is a workaround for bugs (or more precisely sub-optimal behaviors) in other compositors, not in niri. But given that all other compositors work this way I dont have much choice in the matter. So sending one extra event that's harmless will allow kitty to work or if you really dont want to do that, I can try to detect niri and not wait on it. |
|
Here I attach the log from Hyprland as an example: Notice how it send two fractional scale events each of scale 1, one before the surface is configured and one after the surface is configured and has a buffer attached. If the scale were not 1 the second one would cause a resize. |
It's a compositor problem, I'm not sure who all are in this case, all I know don't do so, and in anyway spec has it written down https://wayland.app/protocols/xdg-shell#xdg_surface .
that's from the spec, which means that they should send the scale along the first configure dance, thus you don't have sizes. If you really want to workaround bugs in compositor buy delaying startup, sure, but pretty much all wayland devs would tell you that it's a hyprland bug that it sends scale 1. |
|
Shrug. I tested all the major compositors at the time I wrote that code and they all send fractional scale after configure causing unnecessary resizes. Maybe things have improved since, I dont know, but I doubt it. It's nice that the spec considers that a bug, but I have to deal with the real world and in the real world compositors send fractional scale after the initial buffer is attached. Here is a log from current sway (1.10) for example: Fractional size comes after buffer is attached in configure event. Hyprland is unusual in that it sends a fractional scale of 1 before configure and the real fractional scale after, but that's it. It also sends the actual fractional scale after. |
|
sway resizes way more than it should anyway iirc, so waiting for scale saves nothing on it. The initial size you'll on sway is always (0,0) which means pick yourself, and the real one comes after you've committed a buffer iirc. So it doesn't really save here anything. I'm pretty sure hyprland will fix this bug if it'll be raised with them, they just probably not aware about it...
IIRC it's not just niri who is doing that, I could be wrong but IIRC kde is also doing so, and other compositors could start as well. The issue is not just in niri, but any compositor that uses library smithay, since it's handled in it, so cosmic, etc, etc. |
|
Hm, seems like current GNOME sends both fractional scale and preferred_buffer_scale before the initial configure, even for scale = 1. Guess if GNOME does, then clients may easily start relying on this indeed, so we should make Smithay also send preferred_buffer_scale even when it's 1. |
|
On Tue, Jan 21, 2025 at 12:42:17AM -0800, Kirill Chibisov wrote:
sway resizes way more than it should anyway iirc, so waiting for scale saves nothing on it. The initial size you'll on sway is always (0,0) which means pick yourself, and the real one comes after you've committed a buffer iirc. So it doesn't really save here anything.
On the contrary waiting for scale works fine, I didn't post the full log
above but if I had you would see that there are no more resizes after
the fractional scale is sent.
I'm pretty sure hyprland will fix this bug if it'll be raised with them, they just probably not aware about it...
I certainly hope they do. Ping @vaxerski
>So sending one extra event that's harmless will allow kitty to work or if you really dont want to do that, I can try to detect niri and not wait on it.
IIRC it's not just niri who is doing that, I could be wrong but IIRC kde is also doing so, and other compositors could start as well. The issue is not just in niri, but any compositor that uses library smithay, since it's handled in it, so cosmic, etc, etc.
Well, like I said above I can either detect niri or detect hyprland.
You have motivated me to special case hyprland instead of niri.
I will consider a fractional scale of 1 as final unless
the compositor is Hyprland. That should fix this issue with smithay
based compositors since they send a fractional scale of 1 before
they configure so kitty will consider that final and not wait for
further fractional scale events.
|
it was raised once, but it's not invalid behavior and I shrugged it off. If it causes issues, I can look into it. Would be nice if someone opened an issue over at hyprland. |
It means that the first frame is rendered at low res, thus a not perfect -> bug, and wayland doesn't really like that, hence why we have all those new scale events in the first place. applies both to surface v6 and fractional. I decided not to ping, since one should open an issue, but not sure I would be the one. |
|
Done: hyprwm/Hyprland#9126 |
|
Opened a Smithay issue about sending the initial preferred buffer scale = 1: Smithay/smithay#1640 |
Describe the bug
I seem to be running into the same issue as described in #7540, but with niri instead of labwc.
To Reproduce
Steps to reproduce the behavior:
niriwithkitty:niri -- kitty.Environment details
Additional context
1.0in theniriconfiguration, the shell starts instantly if any other scale is used.niri, with the following response (that I don't understand fully):The text was updated successfully, but these errors were encountered: