Make double buffering of Terminal adopt to higher monitor zooms

[HeikoKlare]

The terminal implementation uses a custom double buffering implementation for rendering the current line. On most Platforms (Linux and MacOS) the current implementation will always render the double-buffered image at 100% zoom, even if the target zoom is higher.

This change adapts the implementation to directly render into the actual control and enable native double buffering for the control instead. This ensures that the contents are rendered at the actual target zoom, producing sharper results on HiDPI monitors when using MacOS or Linux.

Fixes #2295

Fixes #2191

How to reproduce

MacOS

On MacOS, have a two monitor setup with one high-resolution and one low-resolution monitor. Start the application on the low-resolution monitor and move the window over to the high-resolution monitor.

Without this change:

With this change:

Linux

On Linux, a single monitor setup with a monitor zoom > 100% is sufficient. It also happens with fractional scales. In the following, you see the appearance with 125% monitor zoom.

Without this change:

With this change:

[github-actions]

Test Results

 1 977 files  ±0   1 977 suites  ±0   1h 39m 8s ⏱️ + 1m 48s
 4 743 tests ±0   4 719 ✅ ±0   24 💤 ±0  0 ❌ ±0 
14 229 runs  ±0  14 047 ✅ ±0  182 💤 ±0  0 ❌ ±0 

Results for commit c3d16c9. ± Comparison against base commit 63797d0.

♻️ This comment has been updated with latest results.

[Copilot]

Pull request overview

This PR updates the terminal text rendering path to avoid custom per-line image double buffering (which rendered at 100% scale on some platforms), and instead relies on rendering directly to the control with SWT native double buffering so output stays sharp on HiDPI / fractional scaling (MacOS/Linux).

Changes:

• Remove per-line Image back-buffer rendering in TextLineRenderer and draw directly to the provided GC.
• Enable SWT native double buffering on TextCanvas via SWT.DOUBLE_BUFFERED.
• Adjust underline drawing API to accept screen offsets (but see comments for a positioning bug).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
terminal/bundles/org.eclipse.terminal.control/src/org/eclipse/terminal/internal/textcanvas/TextLineRenderer.java	Switches line rendering from manual Image double buffer to direct GC painting; updates underline drawing to use offsets.
terminal/bundles/org.eclipse.terminal.control/src/org/eclipse/terminal/internal/textcanvas/TextCanvas.java	Enables SWT native double buffering for the terminal canvas control.

Comments suppressed due to low confidence (1)

terminal/bundles/org.eclipse.terminal.control/src/org/eclipse/terminal/internal/textcanvas/TextLineRenderer.java:191

• drawUnderline(...) uses absolute colStart/colEnd to compute x/x2, but drawLine(...) is often called for a clipped column range (colFirst may be > 0) where x is the screen origin for colFirst. This will misplace the underline whenever the paint clip starts mid-line (and x2 also currently ignores xOffset). Consider computing underline coordinates relative to colFirst (or pass colFirst into drawUnderline) and include xOffset when computing x2 so the line aligns with drawText(...) offsets.

	private void drawUnderline(GC gc, int xOffset, int yOffset, int colStart, int colEnd) {
		int y = yOffset + getCellHeight() - 1;
		int x = xOffset + getCellWidth() * colStart;

		// x2 is the right side of last column being underlined.
		int x2 = (colEnd + 1) * getCellWidth() - 1;
		gc.drawLine(x, y, x2, y);

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.