[win32] Test_org_eclipse_swt_dnd_DND fails

[laeubi]

See https://github.com/eclipse-platform/eclipse.platform.swt/runs/6372153691

the test fails with:

java.lang.AssertionError: Drop received other data as we dragged.
at org.eclipse.swt.tests.win32.Test_org_eclipse_swt_dnd_DND.testImageTransfer(Test_org_eclipse_swt_dnd_DND.java:169)

[jukzi]

reproducible on Win: the transparencyType is different and thus are the pixel differntly

[HeikoKlare]

The test is still constantly failing, e.g.: https://github.com/eclipse-platform/eclipse.platform.swt/actions/runs/4862153146/jobs/8668569934

The reason is the following:
The test first creates a 32bit (RGBA-)bitmap. Since the bitmap does not contain reasonable alpha values upon creation, the Image.getImageData() method assigns 255 as alpha value for every pixel:

eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT/win32/org/eclipse/swt/graphics/Image.java

Lines 1641 to 1643 in 8e8b0b7

	for (int dp = 3; dp < imageSize; dp += 4) {
	data[dp] = (byte) 0xFF;
	}

This behavior has been introduced with 36091a0 to improve compatibility, even though alpha values should actually be stored in the ImageData.alphaData array rather than the data array.

When performing a drag-and-drop operation with this image, the data extraction in ImageTransfer treats these values as proper alpha values and puts them into the ImageData.alphaData array. In consequence, the dropped image has transparency type TRANSPARENCY_ALPHA while the original image has TRANSPARENCY_NONE.

I see basically two options to fix this:

1. Ensure that that the images before and after drag-and-drop operation via ImageTransfer are "completely" equal. The problem is that an image may be dropped from anywhere, so interpreting potentially present alpha values in the data array seems reasonable. In addition, dropped images are always considered to be device-independent bitmaps. In the test case, the original bitmap is device dependent. The only chance for improvement I see here is to completely avoid the situation that an image contains any alpha values within the data array instead of the alphaData array, which would be a follow up to 36091a0.
2. Adapt the test case such that the tested scenario is considered valid. In consequence, the test would consider an image with no transparency mode but alpha values of 255 in the data array and an image with set transparency mode and the alpha values being stored in the alphaData array equal if the pixel rgb values are equal as well.

I would follow approach (2) first to have the test fixed. If someone sees reasons and options for fixing the actual behavior of Image as discussewd in (1), it would be interesting to hear and document them here.

[SyntevoAlex]

I would be happy if this is fixed.
@jonathan-meier maybe you would have a look?

[HeikoKlare]

Just to avoid duplicate work: I can provide a PR to improve the test. But it would be great if someone with more knowledge about / experience in image representation can have a look at whether the current data interpretation/representation should be improved as well.