[Win] StyledText with paint artifacts

[tmssngr]

Describe the bug
Resizing a shell with a StyledText control leaves paint artifacts.

To Reproduce
Run this snippet:

import org.eclipse.swt.*;
import org.eclipse.swt.custom.*;
import org.eclipse.swt.layout.*;
import org.eclipse.swt.widgets.*;

public class StyledTextExample {

	public static void main(String[] args) {
		final Display display = new Display();
		final Shell shell = new Shell(display);
		shell.setLayout(new FillLayout());
		final StyledText styledText = new StyledText(shell, SWT.BORDER | SWT.V_SCROLL | SWT.H_SCROLL | SWT.MULTI);
		styledText.setText("line 1\nline 2\nline 3\nline 4\n");
		shell.setSize(400, 300);
		shell.open();
		while (!shell.isDisposed()) {
			if (!display.readAndDispatch()) {
				display.sleep();
			}
		}
		display.dispose();
	}
}

and resize the shell to become larger.

Expected behavior
There must not be repaint artifacts.

Screenshots
Initial display (Windows 11, 175% zoom):

After resizing a little bit:

Environment:

1. Select the platform(s) on which the behavior is seen:

• • All OS
• • Windows
• • Linux
• • macOS

[Phillipus]

Confirmed at 175% zoom, but not 150% or 200% zoom.

• Windows 11
• Monitor 3840x2160
• Java 21
• Latest SWT commit

[Phillipus]

The artifacts are from the control's border (SWT.BORDER) and are drawn when there are also scroll bars.

[tmssngr]

IMHO the border should not be drawn between client area and scrollbars. Without having looked at the exact code, I could imagine that the client area background is drawn one pixel too small (rounded down instead of up?).

The last commit without this regression was 577b1d6.

[HeikoKlare]

The last commit without this regression was 577b1d6.

Note that this is the commit right before monitor-specific scaling was enabled by default for SWT. The problematic behavior is probably inherent to swt.autoScale=quarter (for already longer time) and not specific to the mentioned commit.

Without having looked at the exact code, I could imagine that the client area background is drawn one pixel too small (rounded down instead of up?).

Something like this is likely the case. The problem is that sizes like the client area are used for different purposes, some requiring the value rather to be rounded down and others requiring it to be rounded up to work properly.
We have already invested weeks of work to find solutions for the different size and location values that work for every relevant scenario we were aware of and achieved a state that seems to work quite decent in all use cases that we found to be problematic in the Eclipse IDE and other RCP products. Also the usage of StyledText inside RCP products have not revealed this remaining issue yet. Maybe those usages did not set the SWT.BORDER property.

Just be aware that you can easily run down a rabbit hole when trying to find a holistic solution for this.

[HeikoKlare]

Just saw that I have been working on improving the rounding for client area in this branch:

• https://github.com/HeikoKlare/eclipse.platform.swt/tree/clientarea-rounding

The work was done in context of this issue:

• [Windows] Per-window-auto-scaling broke computerSize(wHint, SWT.DEFAULT) #3119

It is based on the idea of making getClientArea() return a higher-precision Rectangle and making use of it at reasonable places.

[tmssngr]

Maybe a new getClientArea(Rounding r) (Rounding enum { Up, Down }) could return either the rounded up or rounded down size? Then the implementation could decide which one it needs. Non-Windows platforms would ignore the rounding parameter.

[HeikoKlare]

That would not even require new API but would already possible if we returned a higher-precision Rectangle, as done in the changes I have references. You can than wrap it into a Rectangle that is rounded according to what you want to do.
The "problem" is that the rounding behavior is completely encapsulated in SWT. This is by design as you do not want to have consumers bother with that. Until now, we tried to find solutions for rounding-related issues that do not require consumers to deal with rounding behavior. In case we decide that this behavior is supposed to be exposed via API, we would need a holistic concept and not just a single method respecting some rounding information.

[tmssngr]

Yes, a holistic concept would be useful, also in other areas (e.g. GC). But how to solve this new regression? Just draw one pixel more in each direction?

[HeikoKlare]

I see two options for immediate workarounds:

• Turn of monitor-specific scaling.
• Wrap the StyledText into a Composite with the Composite having the border style instead of the StyledText.

Both should of course rather be considered temporary workarounds.

btw: I just saw that we have some SWT examples with StyledText using SWT.BORDER style and showing the same behavior (e.g., JavaViewer, ClipboardExample, TextEditor).