First xdg-shell configure event is invalid #2176
Labels
bug
Not working as intended
Comments
|
My understanding is that the view can create itself but choose not to map immediately. During this delay the user might focus another container, in which case the size it needs could be different. So if we did try to preempt the size when it's created then we'd have to arrange it again when it sends the map request. The positive would be that when it maps, the surface will probably already be the correct size so the transaction would have one less view to wait on. This isn't a huge positive considering it still has to wait for the siblings to resize. It would be fairly complicated to determine what size the view should be without actually arranging its siblings. You'd need a function similar to In my opinion the negatives greatly outweigh the positives. It's a lot of complicated code for something that the user is never going to see. It sounds to me like the recommendation is intended for floating window managers. |
I don't think so. |
|
It must. After we send the configure, the client takes time to create the buffer, then commits or requests to be mapped when it's done. This could take 0ms, or it could take 10 seconds. It would be stupid for the compositor to block the event queue while waiting for the client to map, which means the user might change focus between these operations. |
It's no different than a normal resize operation. If we block when resizing, we can block when mapping. |
|
We can't let clients slowloris the compositor into a standstill. |
|
Also, letting the client choose its initial size itself lets us stow that away and restore it when we float the client later. |
I don't understand.
The official way to do this is to send a 0x0 size. |
|
To fix this, we should create a transaction when the client sends the initial NULL commit. We'd send a configure event with the right size even if the toplevel is currently unmapped. The transaction completes when the client sends an ack_configure and commits a buffer. |
This was referenced Nov 4, 2020
13 tasks
7 tasks
|
Just wanting to add that gstreamer has a good reproducer for this: That crashes completely here, which is probably suboptimal from gstreamer, but that's another story: Here's the full log: |
kennylevinsen
added a commit
to kennylevinsen/sway
that referenced
this issue
Aug 24, 2024
Sending 0,0 as configure dimensions indicate that the client is free to pick its own dimensions. When tiling, the client needs to strictly adhere to the tile dimensions. Sway's handling of this has been to send a the appropriate dimensions in a new configure when the surface is mapped, leading to the first buffer most likely being incorrectly sized. Introduce a view_premap which goes through part of the mapping dance, calculating what the container dimensions would be at this time and sending it as a configure. This is only an estimate and inherently racey if the user very quickly changes focused workspace between surface role commit and first attached buffer, but when it works the client has a chance of getting the first buffer right, when it doesn't it is no worse than it would have been otherwise. Fixes: swaywm#2176
kennylevinsen
added a commit
to kennylevinsen/sway
that referenced
this issue
Aug 25, 2024
Sending 0,0 as configure dimensions indicate that the client is free to pick its own dimensions. When tiling, the client needs to strictly adhere to the tile dimensions. Sway's handling of this has been to send a the appropriate dimensions in a new configure when the surface is mapped, leading to the first buffer most likely being incorrectly sized. Move the majority of the mapping logic to view_premap, issued on the initial role commit rather than when mapping the view. This allow the first configure to be driven by a tree transaction with the appropriate geometr, and allows container siblings to start preparing earlier as well, reducing the new window latency. Fixes: swaywm#2176
kennylevinsen
added a commit
to kennylevinsen/sway
that referenced
this issue
Aug 25, 2024
Sending 0,0 as configure dimensions indicate that the client is free to pick its own dimensions. When tiling, the client needs to strictly adhere to the tile dimensions. Sway's handling of this has been to send a the appropriate dimensions in a new configure when the surface is mapped, leading to the first buffer most likely being incorrectly sized. Move the majority of the mapping logic to view_premap, issued on the initial role commit rather than when mapping the view. This allow the first configure to be driven by a tree transaction with the appropriate geometr, and allows container siblings to start preparing earlier as well, reducing the new window latency. Fixes: swaywm#2176
kennylevinsen
added a commit
to kennylevinsen/sway
that referenced
this issue
Aug 25, 2024
Sending 0,0 as configure dimensions indicate that the client is free to pick its own dimensions. When tiling, the client needs to strictly adhere to the tile dimensions. Sway's handling of this has been to send a the appropriate dimensions in a new configure when the surface is mapped, leading to the first buffer most likely being incorrectly sized. Move the majority of the mapping logic to view_premap, issued on the initial role commit rather than when mapping the view. This allow the first configure to be driven by a tree transaction with the appropriate geometr, and allows container siblings to start preparing earlier as well, reducing the new window latency. Fixes: swaywm#2176
kennylevinsen
added a commit
to kennylevinsen/sway
that referenced
this issue
Aug 27, 2024
Sending 0,0 as configure dimensions indicate that the client is free to pick its own dimensions. When tiling, the client needs to strictly adhere to the tile dimensions. Sway's handling of this has been to send a the appropriate dimensions in a new configure when the surface is mapped, leading to the first buffer most likely being incorrectly sized. Move the majority of the mapping logic to view_premap, issued on the initial role commit rather than when mapping the view. This allow the first configure to be driven by a tree transaction with the appropriate geometr, and allows container siblings to start preparing earlier as well, reducing the new window latency. Fixes: swaywm#2176
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When a client creates a new xdg-surface and commits a NULL buffer, we're supposed to send a configure event with the size of the window. We currently send it with a 0x0 size (which lets the client decides). We only send the first "real" configure event when the client maps (ie. after it has drawn its first frame).
We should send the correct configure event from the beginning.
The text was updated successfully, but these errors were encountered: