The need for images that don't work with Zoom

[n-yasunaka]

All images are now zoomable, and for that reason all images have an imageProvider that controls the image size.
This is great idea but image objects now consume memory because imageProvider takes up memory, which can be problematic if you have a lot of large images.
I think this problem could be solved if we could use an old-style image that doesn't allow zooming, where the image data is stored on the OS side and handled with a handle, rather than having the data stored in the image object itself, but is there no way to do this?

[merks]

Have you measured how much memory is involved?

[n-yasunaka]

With swt version 3.130.0.v20250528-1759, a 4,726,628 byte png file consumed 36,578 kB as an Image object.
When displaying the same png file as an Image with an older swt version (3.115.0.v20210302-1107), only 643 kB is consumed.

[HeikoKlare]

All images are now zoomable, and for that reason all images have an imageProvider that controls the image size.
This is great idea but image objects now consume memory because imageProvider takes up memory, which can be problematic if you have a lot of large images.

Can you elaborate an where/why an image provider consumes (additional) memory? When you run an application on a single-zoom system, images are only loaded for the one zoom that is present. If you have a multi-zoom system and want to benefit from proper scaling for all monitors, there is no way around having images for the different required zooms. If you do not want to use that, you can disable the monitor-specific scaling for your application via system property or preference, see, e.g.: https://eclipse.dev/eclipse/markdown/?f=news/4.36/platform.md#monitor-specific-ui-scaling-as-default-windows-only

If you are referring to the caching of image data inside the image providers, we could think about adding a flag to disable that caching mechanism. It's only there to avoid that an image needs to be loaded from hard drive multiple times (because that's quite inefficient), but if there is a preference of low memory consumption over performance, it could be worth to have a flag that changes the behavior.

[HeikoKlare]

I wonder if it might should be loaded lazy so if I create the image but just dispose it nothing is ever loaded?

That would be nice but that's not possible without violating the current contracts of the Image constructors: they assert to throw exceptions when the given providers do not fulfill certain constraints. In most cases, this requires loading the data once, so it's not possible to do that lazy. The question is whether some consumers may want to throw away this already loaded data after doing the validation instead of caching it.

[n-yasunaka]

I finally understand why it was a problem in my environment. I had to execute drawImage or similar on the created Image and explicitly call ImageProvider's newImageHandle().
I didn't notice this because it was occurring in a part where the Image was being used without being displayed.
Thank you for letting me know.

[HeikoKlare]

Thank you for the clarification!
In that case the effective memory consumption will probably be similar for the old and current version of SWT: the old version always created a handle for such an image, such that according memory was consumed by that OS handle (and did not appear as Java heap space consumption). In the current version of SWT, no handle will be created in such a case but only the image data will be cached, making the memory consumption appear in Java heap space. Maybe one of the two representation is a bit more/less memory efficient, but I/we have never analyzed that. Apart from that, the current implementation has the benefit of not unnecessarily aquiring an OS handle in such a case.

So is there anything remaining for discussion? E.g., is there any need for a flag to disable the caching? Or is everything fine as is with the latest insights?

[n-yasunaka]

the current implementation has the benefit of not unnecessarily aquiring an OS handle in such a case.

I think this is certainly true.

is there any need for a flag to disable the caching?

The Image constructor that uses InputStream uses ImageDataLoaderStreamProviderWrapper, which holds the inputStreamData. It would be nice if there was an option to not hold on to it.

[HeikoKlare]

The Image constructor that uses InputStream uses ImageDataLoaderStreamProviderWrapper, which holds the inputStreamData. It would be nice if there was an option to not hold on to it.

We have two kinds of data stored in the wrappers:

1. Some original data to derive images or data at different zooms from: This applies to the mentioned input stream case but, e.g., also to the case where an image is initialized with an ImageData object. It is necessary to derive image data at different zooms without quality loss.
2. Some cached data to avoid reloading: This applies to all providers having cachedImageData which are only stored to avoid that the same data is retrieved multiple times, in particular from persistent memory. It is necessary to improve performance.

While the discussion so far was about the second point, this last proposal is about the first point.

To me the question arises about what the actual feature request is and how much it is actually needed. It could make sense to provide a configuration option to either disable one of the mentioned kinds of data storage or both at the same time, but I would not be in favor of only implementing specific options for specific constructors (i.e., subsets of the cases 1 or 2) even though other constructors basically use the same concept for storing data and would not be affected by such an option. That would be confusing to users of such an option.