GC#setLineAttributes changes the width of its argument

[Dani-Hub]

Describe the bug
We are in the process of switching from Eclipse 4.26 to Eclipse 4.36 and noticed a behavioral regression involving GC operations related to LineAttributes.

To Reproduce
Create a GC instance and call the setLineAttributes method with the same LineAttributes instance each time. A typical idiom is the following one:

	@Override
	public void paintDataSet(GC graphics, ...) {
		graphics.setAdvanced(true);
		final boolean isAdvanced = graphics.getAdvanced();
		final var oldLineAttributes = graphics.getLineAttributes();
		final int oldAntiAlias = graphics.getAntialias();
		if (isAdvanced) {
			graphics.setLineAttributes(lineAttributes);
			graphics.setAntialias(SWT.ON);
		}
		if (sz > 0) {
			final int[] xy = new int[2 * sz];
			for (int i = 0; i < sz; ++i) {
				final int x = ...;
				final int y = ...;
				xy[2 * i] = x;
				xy[2 * i + 1] = y;
			}
			graphics.drawPolyline(xy);
		}
		if (isAdvanced) {
			graphics.setAntialias(oldAntiAlias);
			graphics.setLineAttributes(oldLineAttributes);
		}
	}

The effect is that on system with a device zoom > 100 the graph painting width increases each time when being drawn. Here the visual effects on our more complex graphic library, which uses exactly the above code idiom:

First call:

Second call:

Third call:

We found that this is caused by the setLineAttributes method in their second code line:

public void setLineAttributes (LineAttributes attributes) {
	if (attributes == null) SWT.error(SWT.ERROR_NULL_ARGUMENT);
--->	attributes.width = DPIUtil.scaleUp(drawable, attributes.width, getZoom()); 
	setLineAttributesInPixels(attributes);
}

Further analysis revealed that this problem could also occur in older versions than 4.36 (Including in 4.26), but under previous default "swt.autoScale" conditions ("integer200"), this issue manifested only under monitor zooms of 200% or larger. And due to the effective default "swt.autoScale" of "quarter" the problem manifests more likely.

Expected behavior
It is expected that repeated calls of the same paint operation using the same LineAttributes instance doesn't change the line width.

Screenshots
See above

Environment:

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

• • All OS
• • Windows (We use only this platform)
• • Linux
• • macOS

2. Additional OS info (e.g. OS version, Linux Desktop, etc)

3. JRE/JDK version
   21

Version since
Eclipse 4.36 or earlier but after 4.26

Workaround (or) Additional context
A possible workaround is to either create a clone of the LineAttributes instance before calling the setLineAttributes method or to provide built-in logic that reverts the line width change after each call of that method.

[HeikoKlare]

I have taken a look into this issue and found that it seem to just have been fixed "by accident". The core of the issue described here is that GC#setLineAttributes() modifies the line attributes passed as method argument. That behavior was changed to use a copy of the passed line attributes in this PR:

• [win32] Apply Operation pattern on GC #2243

This is the according change:

To reflect the pre-existing issue, I have adapted the GC tests accordingly. When executing them on an older state of SWT, the modified test for setLineAttributes fails due to the bug reported here. On master state, the test succeeds:

• Correct GC tests to properly execute at non-default device zoom #2343

@Dani-Hub can you test again with the latest SWT master state to verify that your issue is fixed?

[Dani-Hub]

Thanks @HeikoKlare for the quick reaction! Indeed it looks to me as if my issue was fixed by the refactoring you are pointing to. I'm not able to test it in our code base but by code inspection (including the new test) this looks good to me. I suggest to close my issue as being resolved.

[HeikoKlare]

Great, thank you for the feedback!