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