Unify instantiation of image handles in ImageFileNameProvider

[ShahzaibIbrahim]

Initializing image handle only using initNative method for both the cases where zoom is equal to the filezoom and when its not equal to the filezoom. The handle in case of not equal is created temporarily and destroyed later before calling init.

Dependent on:

• Create handles for ImageDataProvider and ImageFilenameProvider on demand #1898

[github-actions]

Test Results

   510 files  + 1     510 suites  +1   8m 42s ⏱️ +13s
 4 345 tests +37   4 331 ✅ +35   14 💤 +3  0 ❌  - 1 
16 613 runs  +37  16 502 ✅ +35  111 💤 +3  0 ❌  - 1 

Results for commit f2c137b. ± Comparison against base commit 011a490.

♻️ This comment has been updated with latest results.

[HeikoKlare]

There is a failing test for image initialization on Windows, so the change does to not seem to be correct as is.

[ShahzaibIbrahim]

Tests that are failing will be resolved once #1898 is merged. So it makes this PR dependent.

[HeikoKlare]

This PR now basically reverts the commit made to Image recently pushed on master. Please adapt to current behavior of the class first.

[HeikoKlare]

In general, the change looks good. I only have a remark regarding adaptation of gray/disabled images.

[HeikoKlare]

Is it correct to destroy the handle if it was retireved from the zoomLevelToImageHandle map? I guess we should only do that if it was not in that map before (i.e., if it was temporarily created for retrieving the image data), shouldn't we?

[akoch-yatta]

That is confusing, yes, but logically okay. zoom != fileForZoom.zoom(). It is again a place, where we will need to do a second round, when we refactored all the places to be able to better create temporary handles.

[HeikoKlare]

Ah, I see, it is because the calling method Image#getImageData(int) ensures that. I didn't see that. Yes, that's definitely confusing and we should clean up in a second round.