x11: More robust geometry calculations#438
Merged
august64 merged 1 commit intorust-windowing:masterfrom Apr 7, 2018
Merged
Conversation
a0d841e to
1cf8862
Compare
Tested on the following window managers: * Xfwm4 4.12.4 * Mutter 3.26.2 * Muffin 3.6.0 * Budgie 10.4 * Marco 1.20.0 * Compiz 0.9.13.1 * KWin 5.12.3 * Enlightenment 0.22.2 * FVWM 2.6.7 * Awesome 4.2 * i3 4.15 * xmonad 0.13 * dwm 6.1 * Openbox 3.6.1 * Fluxbox 1.3.7 * Blackbox 0.70.1 * IceWM 1.3.8 * IceWM 1.4.2
Merged
4 tasks
tmfink
pushed a commit
to tmfink/winit
that referenced
this pull request
Jan 5, 2022
bugfix rust-windowing#436 which endless loop in clip::clip_line_segment_to_rect method
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
It was brought to my attention via #430 that there are presently issues with how window geometry is calculated, and I soon found myself in a rather deep rabbit hole.
After testing on Xfwm4, Mutter, Muffin, Budgie, Marco, Compiz, KWin, Enlightenment, FVWM, Awesome, i3, xmonad, dwm, Openbox, Fluxbox, Blackbox, and IceWM, I believe I've arrived at a complete and correct solution.
Normally, this is where I'd explain in depth what this PR does and why it exists, but I wrote some rather extensive comments throughout the source, so I'll just outline the consequences of these changes.
I've verified on all of the WMs tested that
get_position,get_inner_position,get_inner_size,get_outer_size, andset_positionall work correctly, both with and without decorations enabled. The only caveat to this is that I wasn't able to figure out how to test positioning on i3, but i3 isn't on the list of WMs that return different values after this change anyway.The WMs that return different positions after this change are Mutter/Muffin/Budgie, Compiz, and Enlightenment. Fortunately, from my measurements, these are improvements rather than regressions. Explanations for why these values are different are included in the comments.
Enightenment and FVWM now have
set_positionbehavior consistent with other WMs. Once again, explanation in comments.Prior to this,
get_outer_sizewas reliably wrong, as frame extents were being estimated using theborderreturn ofXGetGeometry. On all WMs tested other than xmonad and dwm, that value is always 0. Since the proposedget_inner_positionmethod relies on the same value, it would also be reliably wrong. This PR provides us with accurate frame extents, enabling both of these methods to work correctly.Most of these changes are centered around the
_NET_FRAME_EXTENTSwindow property, which is supported on all widely used WMs. On all WMs tested that don't support it, it's correctly estimated using other values. This PR was inspired by an SFML PR of similar scope.