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 c1a874f8c90a4e915dc0d38bfd494a98b724d247 Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <[email protected]>
Date: Mon, 1 Dec 2025 14:49:21 +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.51.2

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

[github-actions]

Test Results

 3 018 files  ±0   3 018 suites  ±0   2h 9m 44s ⏱️ - 5m 41s
 8 236 tests ±0   7 987 ✅ +1  249 💤 ±0  0 ❌  - 1 
23 628 runs  ±0  22 834 ✅ +1  794 💤 ±0  0 ❌  - 1 

Results for commit c3119c1. ± Comparison against base commit 2d4334f.

♻️ 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).