Adjustment for the Autoscaling-Flag of Eclipse SWT

[Michael5601]

The proposed SVG rasterization feature in this PR introduces the ability to rasterize SVGs at arbitrary resolutions.

As this feature is an enhancement of the current API the output resolution of the rasterized image is selected by calling it with a specific zoom factor. This zoom factor is determined by SWT according to the flag Dswt.autoScale.

Right now the standard value for this flag is integer200 which works as follows:

• For native zoom levels on the main monitor between 100% and 174%, a zoom factor of 100% is applied.
• For zoom levels between 175% and 200%, a zoom factor of 200% is applied.

Under this default setting, no image scaling is performed. This behavior is intentional for PNGs, as scaling them mostly produces poor results. However, for SVGs, this approach means the correct resolution is never provided.

To fully leverage the benefits of the SVG rasterization feature, the Dswt.autoScale-flag must be set to exact, enabling the generation of images at the correct resolution.

In summary this discussion is about the question which value should be chosen as standard for the Dswt.autoScale-flag.

My suggestion is as follows:
Since there is no direct way to notify users about the new SVG feature, such as through @Deprecated annotations, I propose setting the default value of Dswt.autoScale to exact. Users can still modify this setting in the eclipse.ini-file, as they currently do to address issues with small icons on high-DPI monitors.

[BeckerWdf]

I propose setting the default value of Dswt.autoScale to exact

What will be the effect on existing PNGs? Will scaling them with exact create poor results?

[HeikoKlare]

This is how it looks with swt.autoScale=integer200, i.e., with today's default:

Here is a side-by-side comparison (left is integer200/current, right is quarter):

All screenshots are taken with 150% scaling.

[azoitl]

@HeikoKlare unfortunately I have not yet experience with the auto scaling flag. But I know that at least in the RCP using GEF Classic that I'm developing I have issues with certain elements of my GEF drawings not being correctly scaled. This is something I have on my to do list for the beginning of 2025.

I had some discussion with @ptziegler at OCX25. I had the impression he has already more experience then me.

[azoitl]

After re-investigating our drawing issues in Eclipse 4diac IDE's GEF editors and the discussion here I finally understood what is the problem for any GEF based editor where fractional native scaling is set in the OS and Eclipse Platform is used with the default swt.autoScaling option:

- any text based drawings are scaled with with autoscaling exact because of the OS based text rendering
- any graphics only not based on font sizes are not scaled at all. 

This can lead to strange looking diagrams. I've tested the -Dswt.autoScale=exact option and this produces much more reliable outputs. For 4diac IDE we will use for now per default exact.

For comparison here a compilation of screenshots with first line default -Dswt.autoScale settings and the second line with exact, done on Windows.

One thing that I found interesting is that for 175% native scaling the drawings get very blury. Not yet sure what is the reason for that.

[HeikoKlare]

Thank you for the investigation! I agree that the results with scaling set to exact look more consistent across the different scale levels. This is the result of images and control bounds being sized "properly". It should produce the same results with quarter.

The blurry scaling on 175% is interesting and unexpected. It looks as if the texts have been rescaled after rendering, but I don't see why that should happen as I would expect text to be rendered in the exact scaling required for presentation in the UI.

[azoitl]

Thank you for the investigation! I agree that the results with scaling set to exact look more consistent across the different scale levels. This is the result of images and control bounds being sized "properly".

I would emphasize that this is a bit heaver then only images and bounds. This is for anything that is drawn in GEF based on pixels. In the example above it is the drop shadow, the green triangles, etc. One element for which it is extremely bad is the grid. You can not see that in the example above because in 4diac IDE we reworked the Grid a month ago. Now our grid is based on the distance between two pins (two of the triangles). As this is based on the font size and font size is handled by the OS this is now better. But for any GEF Classic base editor the impact is bigger then I had expected. (I forgot to tag @ptziegler in my last post: @ptziegler this may also be interesting for you). Also we have to keep this in mind for SWT 31.

It should produce the same results with quarter.

Yes I would expect that quater is for the native scaling settings that the test machine offered generate the same results.

The blurry scaling on 175% is interesting and unexpected. It looks as if the texts have been rescaled after rendering, but I don't see why that should happen as I would expect text to be rendered in the exact scaling required for presentation in the UI.

That is the reason I wanted to point it out. What I can say that it was produced on the same machine as the others with the same setup (except native scaling) with the same GEF zoom factor. Just to rule a view things out.

[BeckerWdf]

ok from the screenshots I would say that this is not too bad

[HannesWell]

I agree that changing the default of swt.autoScale to exact or maybe quarter (for a grace period) seems the best compromise.
Scaling just SVG will look far worse than having some PNGs that are only poorly scaled.
But we should only change this default have most of the icons we own in the SDK are migrated to SVG.
This will also make users and developers aware of the new support SVG rendering (of course we should still announce it).

What I generally miss with regard to scaling is the ability to adjust the scaling in the preference UI, even if it would just write the corresponding property value to the ini file.

[HeikoKlare]

I agree that it would sometimes be nice to define the autoscale value via a preference, but we need to be aware that we have far too many scaling modes available and they are not all working as expected (whatever may be expected at all). I guess not so many users know about the ability to change them. If we now provided UI for changing them, the expectations regarding keeping, maintaining and improving them could increase, while I would be in favor of just getting rid of all them. In my opinion, we should aim for only having "exact" (and maybe a custom definition of the zoom if anyone required that) but no "integer", "integer200", "half" or "quarter" as they are all just workaround for issues that should be fixed themselves (or I have been completely missing some specific need for them).

For the new "monitor-specific scaling" that we are currently introducing for Windows, we decided to only support "quarter", "exact" and explicit zoom values (including "false"), as the currently used "integer"/"integer200" (and also "half") modes are too complicated to implement without any real need (except for sharp image scaling, which will mostly be resolved by SVGs).
We will thus make "monitor-specific scaling" use "quarter" autoscale mode (if no other mode else is specified) or any other of the accepted modes in case they are explicitly specified:

• [Win] Disallow autoscale mode "integer" for monitor-specific scaling #1721

This may also help us in the sense that it pushes people to using such an autoscale mode and that it allows us to more easily test with "quarter" mode, as the monitor-specific scaling can be enabled via the preference UI.

[HannesWell]

I agree that it would sometimes be nice to define the autoscale value via a preference, but we need to be aware that we have far too many scaling modes available and they are not all working as expected (whatever may be expected at all).

Unfortunately yes. A colleague of mine uses a 4K monitor under Linux for quite some time now hand had to find a non-trivial combination of env-variables to make it somewhat usable but still has multiple oddities.

In my opinion, we should aim for only having "exact" (and maybe a custom definition of the zoom if anyone required that) but no "integer", "integer200", "half" or "quarter" as they are all just workaround for issues that should be fixed themselves (or I have been completely missing some specific need for them).

Yes, absolutely. Ideally Eclipse would just look good on a high-DPI monitor out of the box respecting the scaling defined by the OS.

But if we change the default of swt.autoScale in SWT, we also have to adapt the Equinox-launcher, otherwise the splash-screen looks bad:

• https://github.com/eclipse-equinox/equinox/blob/a1c46e90ca59dc3e15dde1be7df95fb3c1da11a4/features/org.eclipse.equinox.executable.feature/library/win32/eclipseWin.c#L705-L733