Add support loading images with a size hint

[laeubi]

Currently when loading a SVG image it always uses the size declared in the document but storing an SVG at the size to load the image is not really sufficient as it for example require to store the same SVG multiple times if one wants to load it at different sizes.

This now adds a new parameter to the NativeImageLoader that allows to pass a sizeHintSupplier that when we get a dynamic image will load it at the supplied size. This can then later be used in JFace to retrive the target size from the URL.

@HeikoKlare can you take a look if it makes sense to you? I'm not completely sure about fileZoom and targetZoom here...

[github-actions]

Test Results

  108 files   -  7    108 suites   - 7   13m 11s ⏱️ +57s
4 504 tests  - 56  4 489 ✅  - 55  13 💤  - 3  0 ❌ ±0  2 🔥 +2 
  255 runs   - 56    255 ✅  - 53   0 💤  - 3  0 ❌ ±0 

For more details on these errors, see this check.

Results for commit 1a98d48. ± Comparison against base commit cf6ee39.

This pull request removes 56 tests.

AllWin32Tests ImageWin32Tests ‑ testDisposeDrawnImageBeforeRequestingTargetForOtherZoom
AllWin32Tests ImageWin32Tests ‑ testDrawImageAtDifferentZooms(boolean)[1] true
AllWin32Tests ImageWin32Tests ‑ testDrawImageAtDifferentZooms(boolean)[2] false
AllWin32Tests ImageWin32Tests ‑ testImageDataForDifferentFractionalZoomsShouldBeDifferent
AllWin32Tests ImageWin32Tests ‑ testImageShouldHaveDimesionAsPerZoomLevel
AllWin32Tests ImageWin32Tests ‑ testRetrieveImageDataAtDifferentZooms(boolean)[1] true
AllWin32Tests ImageWin32Tests ‑ testRetrieveImageDataAtDifferentZooms(boolean)[2] false
AllWin32Tests ImageWin32Tests ‑ test_getImageData_fromCopiedImage
AllWin32Tests ImageWin32Tests ‑ test_getImageData_fromImageForImageDataFromImage
AllWin32Tests TestTreeColumn ‑ test_ColumnOrder
…

[HeikoKlare]

Great to see further interest in adopting sophisticated image loading/SVG features.

But I have to admit that I do not understand the necessity for this change. In particular, the first sentence of the PR description is not true:

Currently when loading a SVG image it always uses the size declared in the document but storing an SVG at the size to load the image is not really sufficient as it for example require to store the same SVG multiple times if one wants to load it at different sizes.

There is already SVGFileFormat#loadFromByteStreamBySize() and NativeImageLodaer#load() accepting a requested size, so it's not clear to me why we need yet other methods that combine zoom and size information. Currently, they are properly separated as I either want to load an image at it's original size (maybe in a zoomed version) or I want to load it at a specific size. In case fallbacks from one to the other are needed, this can (and even is already now) implemented in the Image class (for the case you cannot load/rasterize an image at a specified size).

In my opinion, this PR needs a demonstration of an adoption of the changes to understand which use cases shall be supported. That would allow to assess whether the current proposal fits to those demands or how a fitting solution would need to look like.

[laeubi]

As said the caller can not know if this is a fixed or dynamic sized image, I have pushed the corresponding Jface changes now here:

• Detect the desired size from the path or Query parameters. eclipse.platform.ui#3431
  the other important part is that almost all icons / images in a usual application are loaded through URLs and ImageDescriptor and at many places (e.g. plugin.xml and e4xmi) you can't even control how it is loaded at all.

[HeikoKlare]

Thank you for sharing the JFace change. That helps to better understand the use case.

As said the caller can not know if this is a fixed or dynamic sized image,

We already have FileFormat#isDynamicallySizable() just like the FileFormat#canLoadAtZoom() which is already used by the URLImageDescriptor. If we want to move the responsibility for identifying the proper way to load some data at the best possible size to the FileFormat/ImageLoader, we should do that consistently, also for the existing functionality. But I am not sure if that would be the right place to do it, as it would put pretty much responsibility for different ways of loading images to the FileFormat itself and on SWT side currently all such functionality is wrapped into ImageLoader and/or Image.

No matter which way we go here, is it really intended that this now combines zoom and size information and falls back to zoom if the image is a raster graphics? E.g., when you request an image at 64x64 at 200% zoom, you want it to be loaded at 128x128 pixel if the image is an SVG and you want it at 200% of whatever the original size is if it's a raster image? At least that's how I understand the current implementation.

But maybe I don't get the full picture yet. I am currently on mobile and will try to have another look next week when I am back in the office.

[laeubi]

@HeikoKlare I mostly tried to get it working as I don't understand the full zoom handling here that somehow uses two zoom factors.

The bottom line is: one somehow needs to "hint" the SVG loader that even the SVG document uses e.g. 1024x1024 pixel as its "native" size it should be rendered as a 16x16px image and by how we use images I can't use any (mostly internal) images and of course zooming should work as well. So yes it is intentional that it does not applies to raster graphics (what usually it is good to store them at the target size to safe space and have maybe a low resolution variant.

So given I have a hint of 16x16px and a current zoom of 200% the result should be an image of 32x32 pixel as if I would have been using two static images that are 16x16px and a @2x variant of that thing that has 32x32 pixels.