Skip to content

Wrong type of ImageData generated by smooth scaling #228

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
HeikoKlare opened this issue Feb 5, 2025 · 10 comments · Fixed by eclipse-platform/eclipse.platform.swt#1824
Closed
Assignees
Labels
HiDPI A HiDPI-Related Issue or Feature SWT Issue for SWT
Milestone

Comments

@HeikoKlare
Copy link
Contributor

HeikoKlare commented Feb 5, 2025

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:

@HeikoKlare HeikoKlare added this to HiDPI Feb 5, 2025
@HeikoKlare HeikoKlare converted this from a draft issue Feb 5, 2025
@HeikoKlare HeikoKlare added this to the 4.35 M3 milestone Feb 5, 2025
@HeikoKlare HeikoKlare added SWT Issue for SWT HiDPI A HiDPI-Related Issue or Feature labels Feb 5, 2025
@ShahzaibIbrahim ShahzaibIbrahim moved this from 🔖 Ready: Atomic to 🏗 In Work: Short in HiDPI Feb 5, 2025
@ShahzaibIbrahim ShahzaibIbrahim self-assigned this Feb 5, 2025
@ShahzaibIbrahim
Copy link

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
Copy link

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
Copy link

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.

Image

@HeikoKlare
Copy link
Contributor Author

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
Copy link

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

Image

@HeikoKlare
Copy link
Contributor Author

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
Copy link

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 .

@HeikoKlare
Copy link
Contributor Author

I would agree to guard the smooth scaling for image type ICON .

Given that it's about transparency mask, we should probably guard it with transparency type "mask". Since the scaleImageData method does not receive an image but only image data, that would even be "better", because the information about image type "Icon" is not present here.

Can you propose an according change?

@ShahzaibIbrahim
Copy link

ShahzaibIbrahim commented Feb 11, 2025

We have information about type in ImageData maskPad. We can guard it by checking if it's of type SWT.TRANSPARENCY_MASK.

@HeikoKlare
Copy link
Contributor Author

There is ImageData#getTransparencyType().

@ShahzaibIbrahim ShahzaibIbrahim moved this from 🏗 In Work: Short to 👀 In Review in HiDPI Feb 12, 2025
@github-project-automation github-project-automation bot moved this from 👀 In Review to ✅ Done in HiDPI Feb 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
HiDPI A HiDPI-Related Issue or Feature SWT Issue for SWT
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants