[GTK] Use primary monitor for device zoom on multi-monitor setups

[vogella]

On GTK, Display._getDeviceZoom(long) ignored its monitor argument and always queried the monitor at virtual coordinate (0,0); Device.getDeviceZoom() did the same on GTK3. On mixed-DPI multi-monitor setups this made every shell pick up the (0,0) monitor's scale factor, so a HiDPI laptop panel positioned at the top-left of the virtual screen would force shells on a standard-density secondary monitor to render at 2x.

This change honors the passed monitor handle in _getDeviceZoom and selects the GDK primary monitor for the initial Display zoom on GTK3, falling back to the (0,0) monitor only when no primary is available (e.g. on Wayland). Monitor.zoom values returned by getMonitors() on X11/Xwayland are now per-monitor instead of all reflecting the (0,0) monitor.

Fixes #3273

[github-actions]

Test Results (linux)

   94 files  ±0     94 suites  ±0   14m 36s ⏱️ -7s
4 597 tests ±0  4 373 ✅ ±0  224 💤 ±0  0 ❌ ±0 
3 383 runs  ±0  3 308 ✅ ±0   75 💤 ±0  0 ❌ ±0 

Results for commit 6ea4c3f. ± Comparison against base commit b40fe94.

♻️ This comment has been updated with latest results.

[Copilot]

Pull request overview

Fixes incorrect zoom/DPI selection on GTK multi-monitor setups by ensuring SWT queries the intended monitor (or a sensible default) rather than always using the monitor at virtual (0,0). This aligns shell rendering scale with the monitor the shell is actually on and fixes per-monitor Monitor.zoom reporting on X11/Xwayland.

Changes:

• Update Display._getDeviceZoom(long) to honor the passed GdkMonitor handle and only fall back to primary / (0,0) when no monitor is provided.
• Update GTK3 Device.getDeviceZoom() initialization logic to prefer the GDK primary monitor, falling back to (0,0) when needed.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Display.java	Uses the provided monitor handle when computing zoom, fixing per-monitor zoom reporting on GTK3 X11.
bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/graphics/Device.java	Sets initial GTK3 device zoom from the primary monitor (with fallback), improving default scaling on multi-monitor setups.

[akurtakov]

This looks good. Unfortunately, I don't have a multimonitor setup to test right now.
FWIW, on X11 monitor at 0,0 was the primary monitor but with Wayland this is no longer mandatory .

[HeikoKlare]

Conceptually, the change looks sound. I have currently no chance to test it. But from how I understand the control flows, one of the changes seems obsolete and maybe there is further potential for simplification/DRY, see the specific comment.

[HeikoKlare]

I find this method and the change to it a bit confusing. It only seems to be called from a code branch is is specific to X11 + GTK3. According to @akurtakov, in that combination the monitor at 0,0 and the primary monitor are the same anyway, so this change should be obsolete (see #3274 (review)). Since the method originally did not use the passed monitor anyway, should there rather be a getPrimaryMonitor() method used at both placed changed in this PR?

[vogella]

The change isn't obsolete: the primary-monitor fallback only runs when monitor == 0 (and yes, that's a no-op on X11+GTK3).

The fix is honoring the non-zero handle, since getMonitors() (Display.java:2715) passes monitor.handle per monitor and the old code ignored it, making every Monitor.zoom identical.

getPrimaryMonitor() helper sounds ok to me, it is just three lines but I can adjust the change accordingly.

[HeikoKlare]

If that's true, it's a bug completely independent of this PR. Are you sure the assessment is correct? To me it sounds as if the zoom set to a monitor on X11 / GTK3 should effectively be the one of the primary monitor to make SWT work correctly (which is why the method argument is ignored). If that is not the case, then your change is probably correct but, as said, independent of the purpose of this PR.

[vogella]

I fail to understand your response. Without this patch my primary monitor is not used, it always uses the monitor in the fixed coordinates. So Eclipse starts completely broken on my primary device. If I start it on my laptop it starts fine, as this fits to the hard code coordinates

[HeikoKlare]

Are you using Wayland or X11? I understood this comment #3274 (review) as if the change should effectively be a no-op on X11 because primary monitor zoom and zoom at (0,0) should be equal. And when using Wayland, this method is not called anyway.