[Win32] Ensure consistent image data returned for data-based images

[HeikoKlare]

Due to the on-demand creation of image handles, there is not necessarily a handles anymore from which image data is retrieved when requesting is via the getImageData(...) methods. This results in potentially different kinds of image data (including different anti-aliasing results) depending on whether a handle has already been created for an image at the given zoom or not.

This change adapts the implementation of Image based on static ImageData and streams to always use the image data retrieved from a native handle. To this end, it temporarily creates a handle if necessary. In order to avoid repeated loading and handle creation for the same source of image, a cache for the already retrieved image data is introduced.

⚠️ This is based on and should thus be merged after #2036

Fixes #2052

Supercedes and thus closes #2051

[github-actions]

Test Results

   539 files  ±0     539 suites  ±0   29m 3s ⏱️ +51s
 4 337 tests +1   4 321 ✅ +1   15 💤 ±0  1 ❌ ±0 
16 601 runs  +4  16 463 ✅ +2  137 💤 +2  1 ❌ ±0 

For more details on these failures, see this check.

Results for commit ab716d9. ± Comparison against base commit 504c82b.

♻️ This comment has been updated with latest results.

[akoch-yatta]

Code looks good to me except the one question/remark, I have. I still need to do some testing.

[akoch-yatta]

@HeikoKlare As I already had the change drafted some time back, I wrapped that up and created #2027 to make sure imageProvider is always != null, which makes my comment not relevant anymore. I would propose to process that one first

[fedejeanne]

I tested this and it looks good. I would even change the commit-text and add the it contributes (or even fixes) #2052. I'm not sure if one can call it a "fix" because I always compare these 2 constructors of Image:

1. public Image(Device device, ImageData data) {...}
2. public Image(Device device, Image srcImage, int flag) {...}

and the 2nd one produces sharper images.

That being said, I also tested constructor nr. 1 in a for-loop, like this:

Image image = new Image(cachedFolder.getDevice(), clonedImageData);
for (int i=0; i<15; i++) {
	// Try to make it even more blurry
	image = new Image(image.getDevice(), image.getImageData());
}

return image;

And it doesn't matter how many times I iterate, the returned image has always the same quality/sharpness.

[HeikoKlare]

I have rebased this on the cleanup PR:

• [win32] Cleanup image wrappers #2036

This required minor adaptations as the adapted image provider wrapper needs to take into account the specific handling for ICON-type images to avoid errors during smooth scaling.

[akoch-yatta]

Had a second look after the rebase. Changes still look fine to me

[fedejeanne]

I retested it and I saw no problems with this PR ✔️

[HeikoKlare]

I tested this and it looks good. I would even change the commit-text and add the it contributes (or even fixes) #2052. I'm not sure if one can call it a "fix" because I always compare these 2 constructors of Image:

1. public Image(Device device, ImageData data) {...}
2. public Image(Device device, Image srcImage, int flag) {...}

and the 2nd one produces sharper images.

I missed this for the previous update of the PR. I just adapted the commit message and added an according fixes keyword to the PR description to auto-close the referenced issue.

The copy constructor for image will of course always produce better results than one taking a specific ImageData, as that specific ImageData represent the image at one single zoom and all other zooms have to be (badly) generated out of it while an "ordinary" image usually only contains the meta-information to retrieve the ImageData for any zoom in the best way (like rasterizing an SVG, loading a hi-res PNG or the like).

[HeikoKlare]

Version increment check is failing for infrastructure reasons and no further version bump is required here.

Windows test failure is known and unrelated: #1843