[Win32] Remove obsolete fallback for drawing text without GDI+

[HeikoKlare]

❗This is an experimental PR to test if the current "fallback" logic is actually obsolete.

A check in GC.drawText() make the implementation fall back to the text rendering based on glyphs and their positions calculated by GDI even when GDI+ is used in all cases except when it contains specific characters that GDI cannot handle. This was necessary more than a decade ago because specific Chinese characters were not properly rendered by GDI+. But this is quite non-intuitive as in case GDI+/advance mode is enabled the consumer will usually expected GDI+ to be used for rendering. In addition, the problematic scenario from back then works fine now.

This change thus adapts the GC.drawText() implementation to use plain GDI+ whenever it is enabled and removes all existing fallback code. It also adds a case for not drawing line delimiters when an according style flag is set, which was not considered by the GDI+ implementation yet.

May fix #3091

[github-actions]

Test Results (win32)

   33 files  ±0     33 suites  ±0   4m 10s ⏱️ -59s
4 717 tests +1  4 641 ✅ +1  76 💤 ±0  0 ❌ ±0 
1 246 runs  +1  1 222 ✅ +1  24 💤 ±0  0 ❌ ±0 

Results for commit 7269ed0. ± Comparison against base commit 450ece0.

♻️ This comment has been updated with latest results.

[HeikoKlare]

Interestingly, this change would also have an impact on some issues reported to GEF (@ptziegler fyi).

It seems like the following fix would be come obsolete as I see the behavior also fixed with this PR:

• [Win32] Fix incorrect font scaling when Transform is used eclipse-gef/gef-classic#963

Without this change on 150% monitor:

With this change on 150% monitor:

For the underlying issue and the snippet posted there, I rather see a change that I would consider a regression caused by this PR:

• SWTGraphic scaling inconsistent across platforms eclipse-gef/gef-classic#945

This is how it looks without this change on 100%:

And this is how it looks with this change on 100%:

But comparing the position of the text on 100% monitor with its position on 150% monitor, the behavior after this change seems to be even more "correct".

Anyway, it seems like the Win32 GC.drawText() implementation has some severe flaws when using advanced mode / GDI+. I am just a bit afraid that simply removing all the code for falling back to GDI and completely relying on GDI+ for all text rendering when advanced mode is enabled may have unintended side effects. But checking some of the bugs for which this implementation has been made (such as https://bugs.eclipse.org/bugs/show_bug.cgi?id=289244 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=305815) and running the snippets used back then without any issues after this change, hopefully GDI+ was improved so much throughout the years that all these workarounds are not necessary anymore.

[HeikoKlare]

Testing approach and additional findings

To validate this change more thoroughly and guard against regressions, I (with assistance from GitHub Copilot) added:

• 19 additional automated regression tests in GCWin32Tests, comparing rendered output between the default (fixed) GDI+ text rendering path and the legacy fallback restored via the org.eclipse.swt.internal.win32.useGDITextRenderingWithGDIP system property. Beyond the underline/strikeout scenario from the reported issue, coverage now includes:

  • Style-decoration combinations (bold/italic + underline/strikeout)
  • Mnemonic/accelerator underlining
  • Mirrored/RTL text
  • Complex scripts and charsets (Arabic, Hebrew, CJK, Cyrillic, Greek, combining diacritics)
  • Kerning-sensitive text width
  • Tab stop expansion

• Snippet395, a manual/visual companion snippet that renders the same set of text properties side-by-side, with two checkboxes to toggle at runtime (no restart needed) between plain GDI and GDI+ (advanced) rendering, and - while GDI+ is active - between the default and legacy text rendering path, to visually compare the output.

Finding: tab stop size regression

While building out this coverage, we found that the tab stop width computed by the GDI+ drawText path (drawTextGDIP) differs from both plain GDI and the legacy GDI+ fallback path: it used 8x the width of a single space glyph as measured by GDI+, whereas the other two paths use 8x GDI's average character width (TEXTMETRIC.tmAveCharWidth), matching the long-standing Win32 DrawText()/TabbedTextOut() convention. Since a space glyph is typically narrower than the average character width, this made tab stops shrink noticeably (roughly by half) whenever the default GDI+ path was used, compared to plain GDI and the legacy fallback.

We fixed this by having drawTextGDIP reuse the same TEXTMETRIC its caller already computes, so tab stops are now sized consistently across all three rendering paths.

Note: This tab-stop discrepancy appears to be a pre-existing bug in the GDI+ text rendering path (unrelated to the underline/strikeout issue this PR addresses) that this PR's change to always use that path simply made visible/impactful by default. It's probably worth splitting the tab-stop fix out into its own separate PR, since it fixes an independent, pre-existing defect rather than something introduced by this change - happy to do that if preferred.

[github-actions]

Test Results

  200 files  ± 0    200 suites  ±0   30m 37s ⏱️ + 4m 10s
4 760 tests +16  4 736 ✅ +16   24 💤 ±0  0 ❌ ±0 
6 908 runs  +16  6 740 ✅ +16  168 💤 ±0  0 ❌ ±0 

Results for commit 7701b89. ± Comparison against base commit 28ddc85.