Make fonts use autoscaled zoom when swt.autoScale is fixed

[arunjose696]

This change ensures that images and fonts share the same zoom level when a fixed autoscale value is used.

Previously, when different GCs were created for images and widgets, their native zoom(GC.data.nativeZoom) levels could differ, causing inconsistencies.

For example, in LineNumberRuler, one GC is created from an image (used for rendering), and another is created from a widget (used for text measurement). The differing native zoom levels between these GCs led to incorrect text width calculations. Specifically, one GC was used to measure the text extent, while the other used those measurements to calculate the width of the columns where the text would be drawn and this resulted in #2311

Steps to reproduce

1)Checkout the first commit. Run steps in #2306
2)Checkout the second commit, this solves the issue with lineNumberRuler

First commit which reverts changes from #2306 Fixes #2361
Second commit fixes the original issue in #2311

[github-actions]

Test Results

   546 files  ±0     546 suites  ±0   30m 55s ⏱️ + 1m 30s
 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 518533c. ± Comparison against base commit 9eea8f6.

♻️ This comment has been updated with latest results.

[HeikoKlare]

The changes look sound to me. I have some proposals and implicit questions whether I understood everything correctly.

[HeikoKlare]

I wonder if this is really the right place/change to TextLayout. We should clarify what the field nativeZoom in TextLayout is supposed to be: is it really a nativeZoom (such as the native zoom of a GC of a StyledText) or it is rather a fontZoom? If it was really a nativeZoom, I would find the change weird because computeRuns calls this method to set the nativeZoom field, which would make it effectively some fontZoom. When I take a look at the usages of nativeZoom, it seems to rather be a fontZoom. Then, however, calling DPIUtil.getNativeZoomForAutoscaleProperty(nativeZoom) would not really make sense here, as nativeZoom already is such an adapted value.
In my understanding nativeZoom should be renamed to fontZoom and then only the change to the first return statement should be applied.

this really the right place for the adaptation in TextLayout()? I see three callers of this method:

• computeRuns() calls it to set a new nativeZoom: shouldn't that native zoom

[arunjose696]

Since the native zoom is set based on a font when a font is applied to a TextLayout, it makes sense to rename nativeZoom to fontZoom.

I reviewed all usages of the variable. There is a minor ambiguity in the getZoom() method, where nativeZoom(now fontZoom) used. This method is called for line and offset operations, which I am slightly not sure if it is directly tied to font . However, since line height and offsets are also influenced by the font zoom, I believe the renaming still makes sense.

[HeikoKlare]

Thank you for the update, looks even cleaner now!

I have only minor comments/proposals left and one question regarding the initialization of the fontZoom (former nativeZoom) in TextLayout.

[HeikoKlare]

The change now looks fine to me. It just has conflicts now because we meanwhile merged #2376.
Could you adapt this PR, @arunjose696?

[arunjose696]

The change now looks fine to me. It just has conflicts now because we meanwhile merged #2376. Could you adapt this PR, @arunjose696?

done

[HeikoKlare]

@arunjose696 since we found that this PR was created under a wrong assumption (fonts to be scaled according to autoscale zoom instead of native zoom when using a fixed autoscale value), I think unfortunately this PR cannot be merged/adapted in a reasonable way. Can we close it or do you see anything of value in it that we should extract into another PR?

[arunjose696]

Closing this PR