windows: Handle scale factor change while window is maximized#35686
Merged
maxbrunsfeld merged 1 commit intomainfrom Aug 5, 2025
Merged
windows: Handle scale factor change while window is maximized#35686maxbrunsfeld merged 1 commit intomainfrom
maxbrunsfeld merged 1 commit intomainfrom
Conversation
orual
pushed a commit
to orual/zed
that referenced
this pull request
Aug 23, 2025
…dustries#35686) Fixes zed-industries#33257 Previously, the scale-factor-change-handling logic relied on `SetWindowPos` enqueuing a `WM_SIZE` window event. But that does not happen when the window is maximized. So when the scale factor changed, maximized windows neglected to call their `resize` callback, and would misinterpret the positions of mouse events. This PR adds special logic for maximized windows, to ensure that the size is updated appropriately. Release Notes: - N/A
rlueder
added a commit
to rlueder/zed
that referenced
this pull request
Sep 15, 2025
When an external monitor is disconnected on macOS, the UI scale factor becomes incorrect because window_did_change_screen only starts the display link but doesn't update the scale factor or trigger resize callbacks. This fix adds a shared update_window_scale_factor helper function that handles scale factor updates and resize callback triggering. Both window_did_change_screen and view_did_change_backing_properties now use this shared function to eliminate code duplication. The approach mirrors the Windows fix in PR zed-industries#35686 for similar DPI change issues. Fixes zed-industries#38229
rlueder
added a commit
to rlueder/zed
that referenced
this pull request
Sep 15, 2025
When an external monitor is disconnected on macOS, the UI scale factor becomes incorrect because window_did_change_screen only starts the display link but doesn't update the scale factor or trigger resize callbacks. This fix adds a shared update_window_scale_factor helper function that handles scale factor updates and resize callback triggering. Both window_did_change_screen and view_did_change_backing_properties now use this shared function to eliminate code duplication. The approach mirrors the Windows fix in PR zed-industries#35686 for similar DPI change issues. Fixes zed-industries#38229
rlueder
added a commit
to rlueder/zed
that referenced
this pull request
Sep 15, 2025
When an external monitor is disconnected on macOS, the UI scale factor becomes incorrect because window_did_change_screen only starts the display link but doesn't update the scale factor or trigger resize callbacks. This fix adds a shared update_window_scale_factor helper function that handles scale factor updates and resize callback triggering. Both window_did_change_screen and view_did_change_backing_properties now use this shared function to eliminate code duplication. The approach mirrors the Windows fix in PR zed-industries#35686 for similar DPI change issues. Fixes zed-industries#38229
localcc
added a commit
that referenced
this pull request
Nov 13, 2025
#38269) Summary Fixes UI scaling issue that occurs when starting Zed after disconnecting an external monitor on macOS. The window's scale factor and drawable size are now properly updated when the window changes screens. Problem Description When an external monitor is disconnected and Zed is started with only the built-in screen active, the UI scale becomes incorrect. This happens because: 1. macOS triggers the `window_did_change_screen` callback when a window moves between displays (including when displays are disconnected) 2. The existing implementation only restarted the display link but didn't update the window's scale factor or drawable size 3. This left the window with stale scaling information from the previous display configuration Root Cause The `window_did_change_screen` callback in `crates/gpui/src/platform/mac/window.rs` was missing the logic to update the window's scale factor and drawable size when moving between screens. This logic was only present in the `view_did_change_backing_properties callback`, which isn't triggered when external monitors are disconnected. Solution - Extracted common logic: Created a new `update_window_scale_factor()` function that encapsulates the scale factor and drawable size update logic - Added scale factor update to screen change: Modified `window_did_change_screen` to call this function after restarting the display link - Refactored existing code: Updated `view_did_change_backing_properties` to use the new shared function, reducing code duplication The fix ensures that whenever a window changes screens (due to monitor disconnect, reconnect, or manual movement), the scale factor, drawable size, and renderer state are properly synchronized. Testing - ✅ Verified that UI scaling remains correct after disconnecting external monitor - ✅ Confirmed that reconnecting external monitor works properly - ✅ Tested that manual window movement between displays updates scaling correctly - ✅ No regressions observed in normal window operations To verity my fix worked I had to copy my preview workspace over my dev workspace, once I had done this I could reproduce the issue on main consistently. After switching to the branch with this fix the issue was resolved. The fix is similar to what was done on #35686 (Windows) Closes #37245 #38229 Release Notes: - Fixed: Update scale factor and drawable size when macOS window changes screen --------- Co-authored-by: Kate <work@localcc.cc>
11happy
pushed a commit
to 11happy/zed
that referenced
this pull request
Dec 1, 2025
zed-industries#38269) Summary Fixes UI scaling issue that occurs when starting Zed after disconnecting an external monitor on macOS. The window's scale factor and drawable size are now properly updated when the window changes screens. Problem Description When an external monitor is disconnected and Zed is started with only the built-in screen active, the UI scale becomes incorrect. This happens because: 1. macOS triggers the `window_did_change_screen` callback when a window moves between displays (including when displays are disconnected) 2. The existing implementation only restarted the display link but didn't update the window's scale factor or drawable size 3. This left the window with stale scaling information from the previous display configuration Root Cause The `window_did_change_screen` callback in `crates/gpui/src/platform/mac/window.rs` was missing the logic to update the window's scale factor and drawable size when moving between screens. This logic was only present in the `view_did_change_backing_properties callback`, which isn't triggered when external monitors are disconnected. Solution - Extracted common logic: Created a new `update_window_scale_factor()` function that encapsulates the scale factor and drawable size update logic - Added scale factor update to screen change: Modified `window_did_change_screen` to call this function after restarting the display link - Refactored existing code: Updated `view_did_change_backing_properties` to use the new shared function, reducing code duplication The fix ensures that whenever a window changes screens (due to monitor disconnect, reconnect, or manual movement), the scale factor, drawable size, and renderer state are properly synchronized. Testing - ✅ Verified that UI scaling remains correct after disconnecting external monitor - ✅ Confirmed that reconnecting external monitor works properly - ✅ Tested that manual window movement between displays updates scaling correctly - ✅ No regressions observed in normal window operations To verity my fix worked I had to copy my preview workspace over my dev workspace, once I had done this I could reproduce the issue on main consistently. After switching to the branch with this fix the issue was resolved. The fix is similar to what was done on zed-industries#35686 (Windows) Closes zed-industries#37245 zed-industries#38229 Release Notes: - Fixed: Update scale factor and drawable size when macOS window changes screen --------- Co-authored-by: Kate <work@localcc.cc>
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.
Fixes #33257
Previously, the scale-factor-change-handling logic relied on
SetWindowPosenqueuing aWM_SIZEwindow event. But that does not happen when the window is maximized. So when the scale factor changed, maximized windows neglected to call theirresizecallback, and would misinterpret the positions of mouse events.This PR adds special logic for maximized windows, to ensure that the size is updated appropriately.
Release Notes: