-
Notifications
You must be signed in to change notification settings - Fork 162
"Smooth" scaling produces blurry images after calling image.getImageData().clone() #2052
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
Comments
Thank you for the report! We will have a look at this. |
I am testing this and I can reproduce it in Windows 10 too. These details are missing in the bug description:
I am testing with 2 monitors, one at 100% and one at 200%. |
I was able to pinpoint the issue: it's the anti-alias that makes the images blurry. I still don't know why is this causing a problem in this particular use-case but commenting out this line in Line 303 in 00c6aef
Alternatively, one can use the I'll add it as a workaround in the description and I will continue to dig deeper tomorrow. |
Defaulting to "smooth" creates blurry images when first displaying the image in a monitor with a high zoom level (e.g. 200%). This is a temporary workaround until https://github.com/eclipse-platform/eclipse.platform.ui/issues/2910 is properly fixed.
Defaulting to "smooth" creates blurry images when first displaying the image in a monitor with a high zoom level (e.g. 200%). This is a temporary workaround until https://github.com/eclipse-platform/eclipse.platform.ui/issues/2910 is properly fixed.
Since today should be the build for M2, I have a workaround in store just in case there is no proper fix in time: #2051 |
@akurtakov FYI Since we've been doing light-weight M* it's generally the build on Friday that is the build that's contributed. And, given all the infrastructure problems, e.g., https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/5892 we might well slip into the weekend and contribute a build from Sunday... |
... the silver lining :-D Thanks Ed! |
I just found out that the issue does not come from cloning the Said in code: private Image getImage(Object obj) {
if (obj instanceof TreeParent) {
if (cachedFolder == null) {
String imageKey = ISharedImages.IMG_OBJ_FOLDER;
cachedFolder = workbench.getSharedImages().getImage(imageKey);
}
// Don't use the constructor with ImageData, use the one with a source Image to copy from
cachedFolder = new Image(cachedFolder.getDevice(), cachedFolder, SWT.IMAGE_COPY);
return cachedFolder;
}
if (cachedElement == null) {
String imageKey = ISharedImages.IMG_OBJ_ELEMENT;
cachedElement = workbench.getSharedImages().getImage(imageKey);
}
ImageData sameImageData = (ImageData) cachedElement.getImageData()/*.clone()*/;
// This constructor still produces a blurry image.
cachedElement = new Image(Display.getCurrent(), sameImageData);
return cachedElement;
} And it looks like this: |
After analyzing the provided sample code more in detail, the issue is that the There is probably something that could be done to support these kind of use cases but in the meantime, can you please tell us where does the snippet of code come from @tobiasmelcher ? Is it adapted from code in Platform or is it in your product? In any case, the code should generated the "original" images only once and, if necessary, produce the "clone" images always based on the original image. |
Btw. after understanding the root cause I tested this issue with #1996 and improves this behavior a lot. |
The code was used in our product ABAP Development Tools in Eclipse. I think we did clone the images by mistake. It was working fine before introduction of the "Monitor-specific UI scaling" feature. I already adapted our code so that the problem does no longer occur. Anyhow, I think that the eclipse behavior changed here in an incompatible way. |
Thank you for the info, @tobiasmelcher . Good to know that it's not code in Platform, this means that there is no need to adapt any more code.
Agreed, the behavior changed. Thank you for reporting it! |
Due to the on-demand creation of image handles, there is not necessarily a handles anymore from which image data is retrieved when requesting is via the getImageData(...) methods. This results in potentially different kinds of image data (including different anti-aliasing results) depending on whether a handle has already been created for an image at the given zoom or not. This change adapts the implementation of Image based on static ImageData and streams to always use the image data retrieved from a native handle. To this end, it temporarily creates a handle if necessary. In order to avoid repeated loading and handle creation for the same source of image, a cache for the already retrieved image data is introduced. Fixes eclipse-platform#2052
Due to the on-demand creation of image handles, there is not necessarily a handles anymore from which image data is retrieved when requesting is via the getImageData(...) methods. This results in potentially different kinds of image data (including different anti-aliasing results) depending on whether a handle has already been created for an image at the given zoom or not. This change adapts the implementation of Image based on static ImageData and streams to always use the image data retrieved from a native handle. To this end, it temporarily creates a handle if necessary. In order to avoid repeated loading and handle creation for the same source of image, a cache for the already retrieved image data is introduced. Fixes eclipse-platform#2052
Due to the on-demand creation of image handles, there is not necessarily a handles anymore from which image data is retrieved when requesting is via the getImageData(...) methods. This results in potentially different kinds of image data (including different anti-aliasing results) depending on whether a handle has already been created for an image at the given zoom or not. This change adapts the implementation of Image based on static ImageData and streams to always use the image data retrieved from a native handle. To this end, it temporarily creates a handle if necessary. In order to avoid repeated loading and handle creation for the same source of image, a cache for the already retrieved image data is introduced. Fixes eclipse-platform#2052
Due to the on-demand creation of image handles, there is not necessarily a handles anymore from which image data is retrieved when requesting is via the getImageData(...) methods. This results in potentially different kinds of image data (including different anti-aliasing results) depending on whether a handle has already been created for an image at the given zoom or not. This change adapts the implementation of Image based on static ImageData and streams to always use the image data retrieved from a native handle. To this end, it temporarily creates a handle if necessary. In order to avoid repeated loading and handle creation for the same source of image, a cache for the already retrieved image data is introduced. Fixes eclipse-platform#2052
Steps to reproduce
From a fresh installation and clean workspace:
simple.zip
Images are no longer blurry after disabling the setting "Use monitor-specific UI scaling" (https://eclipse.dev/eclipse/news/4.36/platform.html#rescaleOnRuntimePreference)
The image is created via following code:
It looks like that data is lost when calling
new Image(Display.getCurrent(), image.getImageData().clone());
when "Use monitor-specific UI scaling" is enabled.Could you please help in fixing this issue?
Thanks a lot,
Tobias
Tested under this environment:
Workarounds
nearest
algorithm to scale images by setting this JVM flag:-Dswt.autoScale.method=nearest
. The results are not optimal but they are not blurry.Image
instead of the one that takes theImageData
.Community
The text was updated successfully, but these errors were encountered: