Use AutoScaleMethod "smooth" by default for fractional scaling #1736
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
Test Results 494 files 494 suites 9m 11s ⏱️ Results for commit 5c293c0. ♻️ This comment has been updated with latest results. |
HeikoKlare
force-pushed
the
autoscalemethod-smooth
branch
from
9118c68 to
f9c3e43
Compare
HeikoKlare
force-pushed
the
autoscalemethod-smooth
branch
2 times, most recently
from
7dcf570 to
7c31518
Compare
HeikoKlare
force-pushed
the
autoscalemethod-smooth
branch
2 times, most recently
from
cbe83fa to
98b7bd6
Compare
akoch-yatta
approved these changes
Jan 21, 2025
Contributor
akoch-yatta
left a comment
akoch-yatta
left a comment
There was a problem hiding this comment.
I had a look into the code. The logic is easy and looks good to me.
Currently, AutoScaleMethod "nearest" is used by default, leading to jagged image scaling results. The method "smooth" is only used on GTK with a fractional scaling value not being a multiple of 100. The reason for not using "smooth" scaling on all platform was a bug regarding icon transparency that has long been resolved. With this change, AutoScaleMethod "smooth" is used by default in fractional scaling scenarios (i.e., with deviceZoom not being an integer multiple of 100) and when using monitor-specific scaling on Windows. To still use "nearest" in these scenarios, it can be activated via system property.
HeikoKlare
force-pushed
the
autoscalemethod-smooth
branch
from
98b7bd6 to
5c293c0
Compare
This was referenced Feb 4, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, AutoScaleMethod "nearest" is used by default, leading to jagged image scaling results. The method "smooth" is only used on GTK with a fractional scaling value not being a multiple of 100. The reason for not using "smooth" scaling on all platform was a bug regarding icon transparency that has long been resolved.
With this change, AutoScaleMethod "smooth" is used by default in fractional scaling scenarios (i.e., with deviceZoom not being an integer multiple of 100) and when using monitor-specific scaling on Windows. To still use "nearest" in these scenarios, it can be activated via system property.
The change has also been tested for GIFs that are only rarely used nowadays. In the screenshots below, the "JobFactory" view uses a GIF as its icon.
Why now?
A better interpolation method was already asked for in: https://bugs.eclipse.org/bugs/show_bug.cgi?id=493455
The issue that previously prevented us from using "smooth" scaling on Windows have meanwhile been resolved:
There are existing workarounds, e.g., for
CompositeImageDescriptor, which should be adapted in a follow-up step as well. See:Is this safe to do?
This change only taken effect when using any
swt.scaleModethat supports fractional scaling, such as the modequarter,exactor an explicit zoom value. None of them used as default value. The default behavior (known as "integer"/"integer200") will not be affected, as the deviceZoom will be multiples of 100.So this change only affects the monitor-specific scaling mode on Windows (which is experimental anyway) and applications where custom configurations of
swt.autoScaleare in place anyway. In those situation, if the new image scaling behavior is undesired,swt.autoScaleMethodmay be custom configured to "nearest" as well.I propose to add an according information in the news for this.
How does it look?
The following screenshots are taken on a 150% monitor with
swt.autoScale=quarter.Before
After