Fix code mining tests on windows if native zoom has value 200

[tobiasmelcher]

No description provided.

[tobiasmelcher]

@travkin79 could you please do me a favor and check if the code minings tests are now also green on your system?
@HeikoKlare it does not look right what I am doing here. Could you please review the code? I have the feeling that gc.copyArea(image, 0, 0); is not working properly on windows when nativeZoom has value 200.

[eclipse-platform-bot]

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

tests/org.eclipse.jface.text.tests/META-INF/MANIFEST.MF

An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch.

Git patch

From bba06cc6db88232e29b8d550fd3a3465989974be Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <platform-bot@eclipse.org>
Date: Wed, 3 Dec 2025 14:00:07 +0000
Subject: [PATCH] Version bump(s) for 4.39 stream


diff --git a/tests/org.eclipse.jface.text.tests/META-INF/MANIFEST.MF b/tests/org.eclipse.jface.text.tests/META-INF/MANIFEST.MF
index c18417e5f9..94755f8e8a 100644
--- a/tests/org.eclipse.jface.text.tests/META-INF/MANIFEST.MF
+++ b/tests/org.eclipse.jface.text.tests/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %Plugin.name
 Bundle-SymbolicName: org.eclipse.jface.text.tests
-Bundle-Version: 3.13.1100.qualifier
+Bundle-Version: 3.13.1200.qualifier
 Bundle-Vendor: %Plugin.providerName
 Bundle-Localization: plugin
 Export-Package: 
-- 
2.52.0

Further information are available in Common Build Issues - Missing version increments.

[github-actions]

Test Results

 3 018 files  ±0   3 018 suites  ±0   2h 16m 42s ⏱️ +36s
 8 236 tests ±0   7 988 ✅ ±0  248 💤 ±0  0 ❌ ±0 
23 628 runs  ±0  22 837 ✅ ±0  791 💤 ±0  0 ❌ ±0 

Results for commit 42a9a54. ± Comparison against base commit d1713be.

♻️ This comment has been updated with latest results.

[travkin79]

Hi @tobiasmelcher,

@travkin79 could you please do me a favor and check if the code minings tests are now also green on your system?

Sure, I'll check the tests today.

[travkin79]

Hi @tobiasmelcher,
I've run the tests on my Windows 11 PC. Some tests fail. Here are the results.

I could also add the stacktraces and screenshots if that helps.

P.S.: For some reason, I had some compilation errors at first (see screenshot). I had to revert some of the last changes to make it compile again. Do I have to update or re-configure something? It seems, the API changed.

[tobiasmelcher]

Hi @tobiasmelcher, I've run the tests on my Windows 11 PC. Some tests fail. Here are the results.

I could also add the stacktraces and screenshots if that helps.

P.S.: For some reason, I had some compilation errors at first (see screenshot). I had to revert some of the last changes to make it compile again. Do I have to update or re-configure something? It seems, the API changed.

Thanks a lot @travkin79 for the very fast response. Do you know which scaling factor you have set in windows? Which nativeZoom value do you get in DPIUtil#setDeviceZoom ? I get on my machine the value 200.

[HeikoKlare]

I have the feeling that gc.copyArea(image, 0, 0); is not working properly on windows when nativeZoom has value 200.

It depends on what the GC is created on. A GC on a display is actually problematic as there is no uniform zoom throughout the display anymore (as every monitor has its own zoom). However, in this case you seem to create a GC on a control to copy it's contents. To the best of my knowledge, that should work. But I would expect that you only get a proper result when retrieving the image data of the image passed to copyArea at exactly the zoom of the control (as otherwise the image data will be scaled to the zoom that you request for). When calling image.getImageData() you will get the data at 100%, so if the control is at 200%, the data will be scaled.

Note that there is currently no good, uniform concept for how to test functionality at a specific monitor zoom. Modifying properties like the native zoom of a control or the zoom in DPIUtil do not work properly, as the former is something you can only do on Windows anyway (there is nothing like a "native zoom" inside a control on MacOS and Linux) and the latter will set a property that has no reasonable meaning on Windows anymore (in case of using monitor-specific scaling) and is not used at all relevant places.
For zoom tests in SWT we have the DPITestUtil, but they are only available inside SWT as they access internal (visibility-restricted) functionality and are also a bit fragile. And note that in general several tests in SWT (and probably also in Platform UI) fail when being executed at a zoom != 100%. So I am not even sure if we have a proper way to make tests like the ones adapted here to work on arbitrary zooms.

One approach that might work is to not modify any zoom data (such as the native zoom of control/GC) but to use image.getImageData(DPIUtil.getDeviceZoom()) and also use DPIUtil.getDeviceZoom() for the calculated zoomFactor to be applied when comparing the image data. I am not sure if that really works, but it could be worth a try.

[tobiasmelcher]

I have the feeling that gc.copyArea(image, 0, 0); is not working properly on windows when nativeZoom has value 200.

It depends on what the GC is created on. A GC on a display is actually problematic as there is no uniform zoom throughout the display anymore (as every monitor has its own zoom). However, in this case you seem to create a GC on a control to copy it's contents. To the best of my knowledge, that should work. But I would expect that you only get a proper result when retrieving the image data of the image passed to copyArea at exactly the zoom of the control (as otherwise the image data will be scaled to the zoom that you request for). When calling image.getImageData() you will get the data at 100%, so if the control is at 200%, the data will be scaled.

Note that there is currently no good, uniform concept for how to test functionality at a specific monitor zoom. Modifying properties like the native zoom of a control or the zoom in DPIUtil do not work properly, as the former is something you can only do on Windows anyway (there is nothing like a "native zoom" inside a control on MacOS and Linux) and the latter will set a property that has no reasonable meaning on Windows anymore (in case of using monitor-specific scaling) and is not used at all relevant places. For zoom tests in SWT we have the DPITestUtil, but they are only available inside SWT as they access internal (visibility-restricted) functionality and are also a bit fragile. And note that in general several tests in SWT (and probably also in Platform UI) fail when being executed at a zoom != 100%. So I am not even sure if we have a proper way to make tests like the ones adapted here to work on arbitrary zooms.

One approach that might work is to not modify any zoom data (such as the native zoom of control/GC) but to use image.getImageData(DPIUtil.getDeviceZoom()) and also use DPIUtil.getDeviceZoom() for the calculated zoomFactor to be applied when comparing the image data. I am not sure if that really works, but it could be worth a try.

Thanks a lot for the response @HeikoKlare .
I think that I observed the following.
When calling following three lines on a widget created with nativeZoom=200, an empty image is created. The image does not represent the contents of the widget .

GC gc= new GC(widget);
gc.copyArea(image, 0, 0);
gc.dispose();

The image was only then properly filled after calling gc.getGCData().nativeZoom= 100;. Did I do something wrong? Or is it ok to override the nativeZoom value of the GCData?
I will try image.getImageData(DPIUtil.getDeviceZoom()) and let you know if this solves the problem.

[travkin79]

Hi @tobiasmelcher,

... Do you know which scaling factor you have set in windows? Which nativeZoom value do you get in DPIUtil#setDeviceZoom ? I get on my machine the value 200.

On my machine org.eclipse.swt.internal.DPIUtil.getDeviceZoom() returns 125. But I have multiple screens. It might depend on the active screen's resolution.

[tobiasmelcher]

I was able to remove the gc.getGCData().nativeZoom= 100; hack by calling image.getImageData(DPIUtil.getDeviceZoom()). Thanks a lot for the hint @HeikoKlare

[HeikoKlare]

On my machine org.eclipse.swt.internal.DPIUtil.getDeviceZoom() returns 125. But I have multiple screens. It might depend on the active screen's resolution.

Note that this value is not very meaningful on Windows anymore (with monitor-specific scaling). Most of its consumers have been replaced. It is basically only there as a "best guess" for cases where some initial zoom is necessary when initializing something (like a resource). Precisely, this value will be updated whenever a shell is moved to a monitor with a different zoom or if the zoom of a monitor changes. This means, if you have multiple shells, the value of DPIUtil#getDeviceZoom() will conform to the zoom of any of them (but you cannot reasonably rely on which of them it is).

[tobiasmelcher]

with [94fe4e0] I switched from DPIUtil#getDeviceZoom() to widget.getShell().nativeZoom to get the zooming level of the Shell to be tested. The tests are now green on my windows machine with zoom level 125. @travkin79 : could you please test again? I don't have a second monitor and therefore cannot test the scenario with different zooming level by monitor.

[BeckerWdf]

That somehow does not compile:

18:23:20.244 [ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:5.0.1:compile (default-compile) on project org.eclipse.jface.text.tests: Compilation failure: Compilation failure: 
18:23:20.244 [ERROR] /home/jenkins/agent/workspace/eclipse.platform.ui_PR-3563/tests/org.eclipse.jface.text.tests/src/org/eclipse/jface/text/tests/codemining/CodeMiningTest.java:[573] 
18:23:20.244 [ERROR] 	int zoom= widget.getShell().nativeZoom;

[HeikoKlare]

See #3563 (comment)

Modifying properties like the native zoom of a control or the zoom in DPIUtil do not work properly, as the former is something you can only do on Windows anyway (there is nothing like a "native zoom" inside a control on MacOS and Linux) [...]

[travkin79]

with [94fe4e0] I switched from DPIUtil#getDeviceZoom() to widget.getShell().nativeZoom to get the zooming level of the Shell to be tested. The tests are now green on my windows machine with zoom level 125. @travkin79 : could you please test again? I don't have a second monitor and therefore cannot test the scenario with different zooming level by monitor.

Hi @tobiasmelcher,
I've run the tests again. Here are the results.

(Locally, I had to revert the version bumps for Eclipse 4.39 and some other changes that lead to compile errors, see comment #3563 (comment).)

[merks]

I think you need to ensure you pull all git repositories in your workspace, update your target platform, and ensure you changes are based on master. Are you using the Oomph setup?

[tobiasmelcher]

See #3563 (comment)

Modifying properties like the native zoom of a control or the zoom in DPIUtil do not work properly, as the former is something you can only do on Windows anyway (there is nothing like a "native zoom" inside a control on MacOS and Linux) [...]

I switched to widget.getShell().nativeZoom instead of DPIUtil#getDeviceZoom() because the zoom level might be not correct in a two monitor setup with different zooming level. I read the Javadoc of Widget#nativeZoom and understand that this attribute is no public API and not available on non-windows platforms. @HeikoKlare: will it be ok if I use reflection here in the test code and check whether nativeZoom attribute is available? My goal is that the code mining tests are also green on windows machines with a two monitor setup and different zooming level. It is somehow irritating for potential contributors if the tests are only green in the central build, but not locally.

[HeikoKlare]

I switched to widget.getShell().nativeZoom instead of DPIUtil#getDeviceZoom() because the zoom level might be not correct in a two monitor setup with different zooming level. I read the Javadoc of Widget#nativeZoom and understand that this attribute is no public API and not available on non-windows platforms

Can you explain why DPIUtil#getDeviceZoom() does not work here? If you only have a single shell, the native zoom of the control/shell and DPIUtil#getDeviceZoom() would be the same.
Using reflection is something I would not recomment, as there is no guarantee that the field persist or persist in it's current semantics, so it will likely break in the future.

[tobiasmelcher]

I switched to widget.getShell().nativeZoom instead of DPIUtil#getDeviceZoom() because the zoom level might be not correct in a two monitor setup with different zooming level. I read the Javadoc of Widget#nativeZoom and understand that this attribute is no public API and not available on non-windows platforms

Can you explain why DPIUtil#getDeviceZoom() does not work here? If you only have a single shell, the native zoom of the control/shell and DPIUtil#getDeviceZoom() would be the same. Using reflection is something I would not recomment, as there is no guarantee that the field persist or persist in it's current semantics, so it will likely break in the future.

Ok, maybe I then misunderstood your first comment. At SAP, we have some magic test setup which is moving the shells to the non main-window. I thought that this logic is also done by the eclipse tests. I unterstood from your first comment, that the Shell zooming level is updated once the shell is moved and DPIUtil#getDeviceZoom() might not return the same value. I therefore thought it is a good idea to use widget.getShell().nativeZoom instead of DPIUtil#getDeviceZoom(). I don't have a multi monitor setup and therefore cannot really test the behavior by myself.

[HeikoKlare]

I unterstood from your first comment, that the Shell zooming level is updated once the shell is moved and DPIUtil#getDeviceZoom() might not return the same value.

My statment was probably a bit misleading: When having a single shell, shell.nativeZoom and DPIUtil#getDeviceZoom() should always have the same value. Problems only arise when having multiple shells, as each of them can have a different nativeZoom, but DPIUtil#getDeviceZoom() can only reflect one of them. In that case, DPIUtil#getDeviceZoom() will return the nativeZoom of the shell that has most recently been moved to another monitor. That behavior is rather by accident, driven by the intent to return a most reasonable value to be used as a heuristic.

Since tests will usually only use a single shell, you should be safe to use DPIUtil#getDeviceZoom() to parameterize something according to the shell's native zoom.

[tobiasmelcher]

Since tests will usually only use a single shell, you should be safe to use DPIUtil#getDeviceZoom() to parameterize something according to the shell's native zoom.

Great, thanks a lot for the clarification. I will then switch back to DPIUtil#getDeviceZoom().

[travkin79]

Hi @merks,

I think you need to ensure you pull all git repositories in your workspace, update your target platform, and ensure you changes are based on master. Are you using the Oomph setup?

Thank you for the hint. I'm using the oomph installer that installed me the latest Eclipse IDE (originally it was 4.38) and checked out the platform.ui projects. Since a few days ago, when starting Eclipse, I get the following screen suggesting an early redirect to Eclipse 4.39. I skipped it, since I was note sure, if I need Eclipse 4.39 already. Today, I performed the redirect suggested by oomph and the compilation issues are gone.