Wrong type of ImageData generated by smooth scaling

[HeikoKlare]

The DPIUtil method for auto-scaling image data

private static ImageData autoScaleImageData (Device device, final ImageData imageData, float scaleFactor)

performs the scaling via drawing the image using an anti-aliased GC into a new image when auto-scale mode SMOOTH is enabled.

The created image, into which the rescaled image is drawn, does not take the characteristics of the original image data into account (e.g., containing a transparency mask) but simply initializes the image with alpha data. One consequence is that rescaling images of type SWT.ICON, which use a transparency mask, lose their transparency mask and thus their image type when rescaling (eclipse-platform/eclipse.platform.swt#1790).

The autoScaleImageData method shall be improved to return image data with the same characteristics (in particular the type of transparency) used by the original data when the auto-scaling mode is SMOOTH.
One possibility might be to apply a similar solution as in eclipse-platform/eclipse.platform.swt#1790 but inside the auto-scaling implementation rather than in a consumer.

See also:

• JVM Crash on monitor changes #214
• SWTException "unsupported color type" when moving between differently scaled monitors #226
• Scaling Icons without transparency #71

[ShahzaibIbrahim]

I tried preserving the state of icon by copying the maskData and maskPad into the resulting data but it failed because gc.drawImage only supports BITMAP. Perhaps that was the reason this information was not copied over.

@HeikoKlare @akoch-yatta

[akoch-yatta]

Ok, then we should try Plan B and adapt the autoscaling as @HeikoKlare described:

One possibility might be to apply a similar solution as in eclipse-platform/eclipse.platform.swt#1790 but inside the auto-scaling implementation rather than in a consumer.

So passing the image type to the autoscale method and adapt the image data (creation) there to add/recreate the transparency data in the image data there

[ShahzaibIbrahim]

No, we dont need to pass the image type to autoscale method. We have that there already. When we call Image original = new Image (device, (ImageDataProvider) zoom -> imageData); This has the type Icon. The issue is that if I we keep the transparency intact before calling the gc.drawImage(), the drawImage method only supports bitmap images otherwise throws an exception.

[HeikoKlare]

The idea would be to draw a bitmap image and then convert it into an icon image (by extracting the imagedata and the mask data and initializing a new image out of it like we did in the PR yesterday).

[ShahzaibIbrahim]

It seems like GC when drawing image of type ICON, doesn't really take care of Icon transparency. Using SMOOTH scaling can lose transparency while USING nearest gives you blurry results. I will just post the comparison here and we can make a decision later.

Comparison for Icon in NEAREST (top) and SMOOTH (bottom) scaling method

[HeikoKlare]

Thank you! The smooth scaling result looks pretty ugly. I wonder what is causing this result. Is is because rendering with an anti-aliasing-enabled GC is not capable of properly considering a transparency mask?

I propose to guard the smooth scaling with whatever type of image is (in)compatible with it, like one having a transparency mask if the answer to above question is "yes".

[ShahzaibIbrahim]

Yes, it is because rendering with an anti-aliasing-enabled GC is not capable of properly considering a transparency mask. I would agree to guard the smooth scaling for image type ICON .