[win32] Fix inconsistency when an Image with GC is drawn on a GC

[akoch-yatta]

This PR adapts the logic when a bitmap or icon is drawn with the GC in the windows implementation. As of now, the autoscale zoom was used to identify the image handle to use. If the image is itself drawn with a ImageGCDrawer, information about the original native zoom was lost, which led to inconsistencies in fonts depending on the auto scale mode. This PR forwards the native zoom in this case to enable the Image to initialize the GC accordingly. This was e.g. an issue with auto scale mode integer200 as described in #2385.

[github-actions]

Test Results

   546 files  ±0     546 suites  ±0   31m 45s ⏱️ +29s
 4 425 tests ±0   4 408 ✅ ±0   17 💤 ±0  0 ❌ ±0 
16 746 runs  ±0  16 619 ✅ ±0  127 💤 ±0  0 ❌ ±0 

Results for commit b0b70ab. ± Comparison against base commit a71bea9.

♻️ This comment has been updated with latest results.

[akoch-yatta]

I noticed that getImageData(int) checks if the image is disposed but getImageMetadata(ZoomContext) doesn't. Couldn't that be a source of issues?

@fedejeanne The image is created few lines above and it will be disposed immediately after it anyway, but I don't see a change this can be disposed before.

[fedejeanne]

In the call that I highlighted everything is fine because image.getImageData(nativeZoom) does check for dispose and, as you say, the image is disposed right away 👍

I was thinking more on the lines of: would it be worth playing it safe and checking for disposal when calling getImageMetadata(ZoomContext)?

At the moment, all calls seem safe because the (direct and indirect) callers check for disposal:

But I was just thinking: is checking for disposal a responsibility of the caller or should the method itself do it?

[fedejeanne]

The changes look fine and I see no regressions.

One nit comment: you need to add this to your commit message @akoch-yatta

Fixes https://github.com/eclipse-platform/eclipse.platform.swt/issues/2311

[HeikoKlare]

I have tested the proposed change with several different setups including combinations of

• two monitors (175% and 100%), each of them once used as primary
• monitor-specific scaling enabled/disabled
• swt.autoScale set to a fixed value (150) vs. not custom specified

and particularly with StyledText (incl. LineNumberRuler) and GEF diagrams.

I did not find any regressions with respect to existing behavior (and with respect to 2025-06) but found the two mentioned issues to be successfully resolved:

• #2311
• #2385

[HeikoKlare]

ftr: this also contributes to eclipse-platform/eclipse.platform.ui#3061