[GTK] Pick largest monitor as device-zoom base when no primary is set#11
Open
vogella wants to merge 1 commit into
Open
[GTK] Pick largest monitor as device-zoom base when no primary is set#11vogella wants to merge 1 commit into
vogella wants to merge 1 commit into
Conversation
Follow-up to b98f360. On Wayland, gdk_display_get_primary_monitor() always returns NULL because the protocol has no notion of a primary monitor, so Device.getPrimaryMonitor(long) fell back to gdk_display_get_monitor_at_point(display, 0, 0). That returns whichever output the compositor happens to anchor at the virtual origin, which is exactly the arbitrary choice issue eclipse-platform#3273 was trying to get rid of: it may pick the HiDPI laptop panel or the standard-density external depending on layout, leaving the initial device zoom dependent on compositor placement. Insert a Wayland-friendly middle step: when no primary is reported, pick the monitor with the largest geometry. This is a stable, compositor- independent heuristic for the user's main work display and matches the answer gdk_display_get_primary_monitor() gives on X11 in the common case. The (0,0) fallback is preserved for single-monitor setups and as a final defensive path. This only improves the startup pick. A single global device zoom still cannot represent a mixed-DPI layout correctly when shells move between monitors; per-monitor rescaling at runtime (as on Win32) is the real fix and is tracked separately. No JNI changes; uses already-bound gdk_display_get_n_monitors and gdk_monitor_get_geometry.
vogella
force-pushed
the
gtk-wayland-zoom-largest-monitor
branch
from
5191641 to
6300294
Compare
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request improves monitor selection in Device.java by introducing a heuristic to pick the largest monitor when no primary monitor is detected, specifically addressing issues on Wayland. The changes include a new pickLargestMonitor method. Feedback was provided to optimize this method by moving the GdkRectangle instantiation outside the loop to avoid redundant object allocations.
I am having trouble creating individual review comments. Click here to see my feedback.
bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/graphics/Device.java (1164-1167)
The GdkRectangle object is instantiated inside the loop. Since it is only used to receive geometry data from the native call, it can be instantiated once outside the loop and reused to avoid unnecessary object allocations.
GdkRectangle r = new GdkRectangle();
for (int i = 0; i < n; i++) {
long m = GDK.gdk_display_get_monitor(display, i);
if (m == 0) continue;
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.
Follow-up to b98f360.
On Wayland,
gdk_display_get_primary_monitor()always returns NULL because the protocol has no concept of a primary monitor, so the fallback inDevice.getPrimaryMonitor(long)was justgdk_display_get_monitor_at_point(display, 0, 0), which arbitrarily picks whichever output the compositor anchors at the virtual origin. That is exactly the behaviour issue eclipse-platform#3273 was meant to fix.This adds a Wayland-friendly middle step: when no primary is reported, pick the monitor with the largest geometry, which is a stable compositor-independent heuristic for the user's main work display and matches the X11 answer in the common case. The (0,0) fallback stays as a defensive last resort for single-monitor setups.
Scope is intentionally narrow.
SWT's GTK port still uses a single global device zoom, so this only improves the startup pick on mixed-DPI Wayland layouts; per-monitor rescaling at runtime (as Win32 already does) is the real fix and is tracked separately.
No JNI changes, no native rebuild required.