Repository navigation
RandR screen change: collapse the notify burst onto the newest event, refresh screen data, realign windows from server truth - #251
Merged
Conversation
…align windows The server defers RRScreenChangeNotify per client until its next request, so the notify burst often starts with a stale duplicate: collapse it onto the last event. XRRGetScreenResources can serve cached state one transition old (RRSetScreenSize does not bump the config timestamp), so refresh the backend screen data from fresh sources before the gui rebuilds NSScreen, then realign mapped windows from the server truth and propagate the corrected origins to the gui, making the backend the single remapper for screen changes. Pairs with gnustep/libs-gui#1006 (gui-side guard against re-applying the old->new delta on an already-realigned frame).
fredkiefer
reviewed
Oct 13, 2026
fredkiefer
reviewed
Oct 13, 2026
fredkiefer
reviewed
Oct 13, 2026
| && (xEvent.xconfigure.window == RootWindow(dpy, defScreen))) | ||
| { | ||
| // Check if other RandR events are waiting in the queue. | ||
| // The server defers RRScreenChangeNotify per client until |
Member
There was a problem hiding this comment.
Could you please advice your LLM to use less verbose comments?
…of fast enumeration, terser comments
Contributor
Author
|
Thanks — fixed in the follow-up commit: braces everywhere, GS_FOR_IN, single-line comments. |
rfm
approved these changes
Oct 14, 2026
rfm
left a comment
Contributor
There was a problem hiding this comment.
This looks good/reasonable to me
Member
|
Richard's approval is good enough for me and I like the idea behind this patch. |
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
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.
Follow-up to #249 and the analysis in that thread.
What this changes in the RRScreenChangeNotify branch
Collapse the notify burst onto the newest event. The server defers RRScreenChangeNotify per client until its next request, so a burst often starts with a stale duplicate of the previous state. The drain now assigns inside the loop: the branch always processes the last (newest) event, and
*eventstays untouched when nothing was drained.Refresh the backend screen data before the gui rebuilds NSScreen. XRRGetScreenResources can serve cached state one transition old (RRSetScreenSize does not bump the resources config timestamp), so resetScreens can derive the previous screen size. Calling
screenList(root geometry + per-CRTC info — the same fresh sources as x11: build single-monitor screen frame from root geometry, not the CRTC #249) before[NSScreen resetScreens]makes the gui see current data.Realign mapped windows from the server truth. After the screen update, each viewable window is re-read via XGetGeometry/XTranslateCoordinates, its os-frame recomputed and cached, and the corrected origin propagated to the gui via GSAppKitWindowMoved. The backend becomes the single remapper for screen changes.
Validation
Container harness (Xvfb + RANDR, WM-less, GSScaleFactor 1.3): a Terminal window's title bar across a 1280×800 → 1024×768 → 1280×800 cycle moves 271 → 270 → 270 px (a 1 px rounding difference), stable across repeated fresh runs and 4-cycle sequences. Without the change the window jumps ±32 px on every cycle.
Note: the full jump fix is two-layer — this PR pairs with the libs-gui guard in
applicationDidChangeScreenParameters:(gnustep/libs-gui#1006), which stops the gui from re-applying the old→new delta onto a frame the backend has already realigned.