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.

[HeikoKlare]

I am still concerned that the proposal mixes up too many things, in particular in such a basic thing as FileFormat/ImageLoader. Here are some thoughts:

• In case I want to tell the image loading that I would like to load/rasterize data at a specific size, why to I need to additionally pass a zoom? I can directly incorporate the zoom into the requested size. I currently do not see why this cannot simply be done in JFace.
• Since raster graphics cannot be loaded at a specified size, you need to make a distinction based on whether you have a dynamically sizable image or not anyway. E.g., the request for bundle:/example.id/icons/obj16/search.png?size=128x128 will usually fail while for SVGs you can pass whatever size you want. Currently, the size parameter would be ignored for raster images, but that will lead to unexpected results, For the above URl, I will probably receive a 16x16 pixels image, which is probably not what I as a consumer want and expect.
• In any case, mixing file zoom and target size does not make sense, as the file toom specifies which zoom the file represents, but that is kind of overwritten by the target size anyway. Lets say you use 200% file zoom, 150% target zoom and a target size of 48x48px, what would you expect? You could say that the file zoom does not matter, so you return 150% of 48x48px, i.e., 72x72px. Here the file zoom would be obsolete. So you could also say that you treat the file at 200% zoom, meaning you consider the 200% file as 48x48 px, which means you want to have 150% of the according 100% version (24x24px), so the result should be at 36x36px. But that would be completely confusion. So in my opinion file zoom and target size should never be used together.
• The concept of zoom is a bit weird anyway or at least becomes more weird when using SVGs: currently, images define the size in which they will be used. It may just be altered based on a zoom. However, it would in many cases conceptually make more sense if an application says "I want to use this image at X by Y pixels" (e.g., a toolbar icon at 16x16 for 100% screens and maybe scaled by some value that could depend on UI scaling or others) and not even encode a size in an image at all. That becomes possible with SVGs. It would make the application decide what image size it wants (in terms of size including scaling) and relieve this UI-specific concepts from image handling. But this implicit size encoding in images is so deeply embedded (e.g., that icons are mostly 16x16) that it would be difficult to get rid of it. Still, this is a good indicator why mixing zooms into size-based image retrieval does not really make sense to me.

Even if we agreed that the current proposal implements expected behavior, I am still convinced that this should not and does not need to be embedded into FileFormat/ImageLoader. For a request of an image with specified size (and zoom), you can check via FileFormat if the image dynamically sizable and in that case just request the image data at the size (altered by zoom). If the image is not dynamically sizable, you can still just request the image for the zoom (which, as said above, does not sound reasonable to me) or deal with the situation in a different way (such as throwin in error). In any case, this should be completely possible on consumer side (i.e., in JFace).

[laeubi]

In case I want to tell the image loading that I would like to load/rasterize data at a specific size, why to I need to additionally pass a zoom? I can directly incorporate the zoom into the requested size. I currently do not see why this cannot simply be done in JFace.

Because then JFace would need to know about zoom changes. I would ask this the other way round: Why does (currently) the ImageFormat at all must know the zoom at all if it all can be done by the caller?

In anyway I would be happy if it would be the case, but wanted to note what was written here, that actually what one want is to override the native size (that is unknown to the caller of the function!) if possible, so everything should just "work as before", so if before a zoom level would be required I don't see why it should now be obsolete because then it would be obsolete in the first place.

Since raster graphics cannot be loaded at a specified size

That's why I explicitly made this as a hint to the provider. A classical raster image would always be loaded at its native size and I don't want to change this (by intention) but for example an ICO format or XPM both support different sizes in the same file as well so possibly could be using the hint as well even though not really broadly used in SWT anyways.

in any case, mixing file zoom and target size does not make sense

As said above, I don't aim at a "target size" at all that why I don't think the feature to raster an image at a given size is suitable. I just want it to tell (a hint) about the initial size at 100% so it can scale this on whatever demands for a zoomed image is given there as if the author of a SVG would have shrink the image at the first place.

The concept of zoom is a bit weird anyway or at least becomes more weird when using SVGs

That's for sure, but it was designed that way before and I dindt aimed to change this in general

For a request of an image with specified size (and zoom), you can check via FileFormat if the image dynamically sizable

The main problem is that even if I could I would completely need to redo what SWT does (and I think not everything is public API) because I literally can't know:

1. What image format has to be used
2. What size the image has

unless I try to load it, so the whole code of content-type detection and image file format selection has to be duplicated at JFace.

In any case, this should be completely possible on consumer side (i.e., in JFace).

That's why I created the PRs so we can play around with that, I think the general idea (extract the size from the URL) is there so if you can came up with a JFace only solution that would be great and maybe help in further refine the proposal either in one way or the other.