Fix GC#drawImage methods with additional Transformation

[al-noori]

If a transform is applied via the GC, then both drawImage APIs consider now the best fitting handle by requesting it through the width/height of the full image scaled by the scaleFactor (relating destination width/height to source width/height) times the width/height scaling induced by the transformation.

Note that only the second commit is relevant for the PR. The first one references to the changes made in #2913.

To easily see and test, use the following snippet:

package org.eclipse.swt.snippets;

import org.eclipse.swt.graphics.*;
import org.eclipse.swt.widgets.*;

public class Snippet389 {

public static void main (String [] args) {
	Display display = new Display ();
	Shell shell = new Shell(display);
	shell.setText("Snippet 389");
	ImageFileNameProvider fileNameProvider = zoom -> {
		if (zoom == 200) {
			return "src/org/eclipse/swt/snippets/eclipse32.png";
		} else if (zoom == 100) {
			return "src/org/eclipse/swt/snippets/eclipse16.png";
		}
		return null;
	};
	Image image = new Image(display, fileNameProvider);
	shell.addPaintListener(e -> {
		e.gc.drawImage(image, 0, 0, 32, 32);
		e.gc.drawImage(image, 0, 0, 16, 16, 0, 50, 32, 32);
	});

	shell.addPaintListener(e -> {
		e.gc.setTransform(new Transform(display, 2, 0, 0, 2, 0, 0));
		e.gc.drawImage(image, 25, 0, 16, 16);
		e.gc.drawImage(image, 0, 0, 16, 16, 25, 25, 16, 16);
		e.gc.setTransform(null);
	});

	shell.open ();

	while (!shell.isDisposed ()) {
		if (!display.readAndDispatch ()) display.sleep ();
	}
	display.dispose ();
}
}

Below are screenshots of the snippet on a 100% zoom.

Before:

After:

Contributes to #2919

[github-actions]

Test Results (win32)

   34 files  ±0     34 suites  ±0   5m 45s ⏱️ + 1m 1s
4 636 tests ±0  4 563 ✅ ±0  73 💤 ±0  0 ❌ ±0 
  170 runs  ±0    167 ✅ ±0   3 💤 ±0  0 ❌ ±0 

Results for commit b629e45. ± Comparison against base commit c35c568.

♻️ This comment has been updated with latest results.

[arunjose696]

Have tested the changes myself and can see it fixes the said issue.

[HeikoKlare]

There is an attempt to fix the issue with wrongly scaled image data being used when a transform is applied for GEF:

• eclipse-gef/gef-classic#925

We should check if that issue is resolved with this PR as well and there is also a snippet in there to may better test these changes.

[akoch-yatta]

LGTM, I only rebased, moved a bit of code around and added a comment with my commits. Still I would ask for a second approval (@HeikoKlare)

I tested especially with Snippet389 and a slightly adjusted version to test with the eclipse16.svg to ensure is is really creating the perfect solution when putting in high scale factors

[HeikoKlare]

I also tested with snippet 389 and an SVG and found this to work fine for the drawImage methods that allow scaling. The drawImage(image, x, y) method is not fixed yet and will be part of a subsequent PR. That one will then also address eclipse-gef/gef-classic#922.

This is the snippet with the eclipse.svg and scale 20 before this change:

This is the snippet with the eclipse.svg and scale 20 after this change:

I've just adapted the commit message to refer to the addressed issue.