Implement smooth resizing on X11 with _NET_WM_SYNC_REQUEST #3771
Conversation
Speykious
force-pushed
the
sync
branch
2 times, most recently
from
ede459d
to
44e0b2a
Compare
There was a problem hiding this comment.
We can do this here. Do extension_information with sync::X11_EXTENSION_NAME and check for None.
I'll test this later once I have more time.
| @@ -469,21 +472,40 @@ impl UnownedWindow { | |||
| leap!(window.set_icon_inner(icon.inner)).ignore_error(); | |||
| } | |||
|
|
|||
| // Opt into handling window close | |||
| // Opt into handling window close and resize synchronization | |||
There was a problem hiding this comment.
Is there a better source of documentation on resize synchronization?
There was a problem hiding this comment.
There's https://www.x.org/releases/X11R7.7/doc/xextproto/sync.html and https://fishsoup.net/misc/wm-spec-synchronization.html, but outside of that there's pretty much just direct implementations like Qt's.
| let lo = (bytemuck::cast::<c_long, c_ulong>(xev.data.get_long(2)) & 0xffffffff) as u32; | ||
| #[allow(clippy::identity_op)] | ||
| let hi = (bytemuck::cast::<c_long, c_ulong>(xev.data.get_long(3)) & 0xffffffff) as u32; | ||
| let hi = bytemuck::cast::<u32, i32>(hi); |
There was a problem hiding this comment.
Do we lose anything by doing as instead of bytemuck::cast?
There was a problem hiding this comment.
The data format is 32 bit numbers. On 64 bit Linux we could just skip the c_ulong conversion entirely, but on 32 bit Linux the c_long and c_ulong types are 32 bit, so the last bit being the sign becomes a problem. So this is done to make sure both 64 bit and 32 bit interpret the data correctly.
Alternatively I could make 2 separate codepaths, one for 32 bit and another for 64 bit. Might be easier to read?
Edit: I did just that, I think it's a bit better.
changelogmodule if knowledge of this change could be valuable to usersResolves #2153.
I only tested this on KDE so far, this probably needs more tests on other DEs and WMs.
One thing I'm unsure about is whether all the widely used DEs and WMs support the sync API. I know KDE and Gnome definitely do, and it seems that awesomewm also does, but I don't know if some other important ones don't. Searching around, I saw that Qt preemptively checks if the sync extension is supported through a
hasXSynccall, but I couldn't find a way to do that withx11rbso right now there's just no checks...On KDE, there's also the subtly weird behavior of the window when resizing a certain way that I mentioned in this C gist that I shared in #2153, but it looks more like a KDE bug to me than a misuse of the API.ok it actually definitely is a KDE bug because it happens to all windows of all applications regardless of whether they support_NET_WM_SYNC_REQUEST.