Enable anti-aliasing for Terminal text

[iloveeclipse]

Fixes Contributes to #2295

[github-actions]

Test Results

 1 977 files  + 27   1 977 suites  +27   1h 35m 47s ⏱️ + 5m 44s
 4 743 tests ±  0   4 719 ✅ +  1   24 💤 ±0  0 ❌  - 1 
14 229 runs  +153  14 047 ✅ +154  182 💤 ±0  0 ❌  - 1 

Results for commit d564755. ± Comparison against base commit 8594fad.

[HeikoKlare]

This change improves the situation for Windows with differing "quality" depending on the actual conditions.
Note that the issue not improved because of using anti-aliasing but because of the implicit enablement of advanced mode for the GC. On Windows, this enabled GDI+, which produces the different results in text extent calculation and/or text rendering. So in my understanding, changing setAntialias(SWT.ON) to setAdvance(true) would also resolve the issue.

On primary monitor
When operating on the primary monitor, the issue seems to resolve cut-off characters on Windows.

Before:

After:

**On non-primary monitor:
When operating on a non-primary monitor, the issue is reduced. In the following example, you see that the text is less cuf-off before the "/"

Before:
You see that the text is less cut-off between before the "/".

After:

Note that the longer a text segment is, the more text will be cut off, e.g.:

This is caused by the font not being interpreted as "proportional" (even though it actually is) on a non-primary monitor because of the wrong usage of a GC for extent calculation in StyleMap as explained here: #2295 (comment)

When adapting the GC creating in StyleMap to use the correct zoom, the results look quite correct with this change even on a secondary monitor:

With that understanding, I would be in favor of merging this. I will try to find a way to properly initialize the GC in StyleMap to further improve the behavior in multi-monitor setups.

[HeikoKlare]

@iloveeclipse just to be sure: you don't want to merge this as a last-minute fix for RC2 but wait for 2026-06, do you?

[iloveeclipse]

you don't want to merge this as a last-minute fix for RC2 but wait for 2026-06, do you?

I believe this could be merged as it should be small & innocent fix, but I believe it is too late for RC2, isn't?
@merks : how are we in time?

If there will be RC2a (usually we have one), this would be good candidate :-)

[merks]

@iloveeclipse @HeikoKlare

The RC2/final build is tonight (I think 6:00PM EST) so we have all day for any safe final changes. I'll leave it to you guys' good judgement as to what is appropriate and safe to merge on the last day of the cycle.

[iloveeclipse]

OK, with that I believe we can merge for RC2.
Heiko, do we need more approvals?

[HeikoKlare]

OK, with that I believe we can merge for RC2.
Heiko, do we need more approvals?

I don't think so. You have my PL+1.

Just for the sake of safety I have tested the change on MacOS and it is fine there as well (in the sense that it does not change any behavior as the text was antialiased already before).

[merks]

You guys are fully empowered to do the right thing in the best interests of the project.

[iloveeclipse]

OK, thanks Heiko & Ed. Merging now.

[HannesWell]

I was looking forward for a nicer rendering of the Terminal content since it was bugging me quiet some time.
And while it looks a little bit better now, unfortunately it became quite laggy for me on Windows-11 with a 4K monitor and 175% scaling. My graphics card is actually powerful, but I don't know if something else has to be configured.
Not only is there a noticeable lag when typing text into the console, it also noticeably slows down the SWT entire layout if I e.g. resize the view containers and takes noticeable time to redraw the content.

[iloveeclipse]

OMG. I see the slower UI repaints on view resize, slower output and slightly slower typing speed in the terminal. The question is whether it is worth to have crisp text inside or not?

@trancexpress : could you please test on Linux with latest SDK build?

Should we revert the change?

[akurtakov]

I would say revert it and have the next cycle to have time to improve. We shouldn't be shipping such regressions as Eclipse is not a speed monster already.

[HannesWell]

OMG. I see the slower UI repaints on view resize, slower output and slightly slower typing speed in the terminal. The question is whether it is worth to have crisp text inside or not?

At least in my setup the situation became a bit better with respect to sharpness of the rendered text but it's not perfect and I still have other artifacts like ghost lines after resize.
And while the terminal does not become unusable, for me personally the gain in sharpness doesn't outweigh the loss in performance.

I would say revert it and have the next cycle to have time to improve. We shouldn't be shipping such regressions as Eclipse is not a speed monster already.

That's my opinion too.

[iloveeclipse]

See #2480

[trancexpress]

@trancexpress : could you please test on Linux with latest SDK build?

Checked with:

Eclipse SDK
Version: 2026-03 (4.39)
Build id: I20260225-1800

I don't see a notable difference to:

Eclipse SDK
Version: 2026-03 (4.39)
Build id: I20260224-2200

Actually no, when I start in my developer workspace resizing is a lot slower. I didn't notice anything in a new workspace, but with some views open and a Java editor, the UI is slower.