NatTable modifications for deprecating Display#getDPI()

[fipro78]

With the efforts in SWT to support monitor specific scaling, the method Display#getDPI() will be deprecated in the upcoming release (see eclipse-platform/eclipse.platform.swt#2260)

NatTable makes use of this method to support scaling of the NatTable according to the display settings. A list of places where it is used in NatTable and other Nebula widgets can be found here: vi-eclipse/Eclipse-Platform#205

The method Display#getDPI() will be marked as deprecated, so it does not mean with the upcoming Eclipse release it is not working anymore. But it makes sense to prepare for that in the near future.

The following is a collection of findings, that will probably be introduced in NatTable. This will increase the minimum required SWT version and probably even add breaking changes, as there is no need to handle different scalings for x and y then.

You can already try to support the monitor specific scaling with NatTable by adding the following modifications locally:

Introduce a new IDpiConverter

public class DefaultMonitorDpiConverter extends AbstractDpiConverter {

    private NatTable natTable;

    public DefaultMonitorDpiConverter(NatTable natTable) {
        this.natTable = natTable;
    }

    @Override
    protected void readDpiFromDisplay() {
        // https://github.com/eclipse-nattable/nattable/issues/139
        Display.getDefault().syncExec(() -> {
            Object zoom = this.natTable.getData("NATIVE_ZOOM"); //$NON-NLS-1$
            int zoomValue = -1;
            if (zoom != null && zoom instanceof Integer) {
                zoomValue = (Integer) zoom;
            } else if (zoom != null && zoom instanceof String) {
                try {
                    zoomValue = Integer.parseInt((String) zoom);
                } catch (NumberFormatException e) {
                    // If parsing fails, fallback to the default zoom
                    zoomValue = Display.getDefault().getPrimaryMonitor().getZoom();
                }
            } else {
                zoom = Display.getDefault().getPrimaryMonitor().getZoom();
            }
            DefaultMonitorDpiConverter.this.dpi = (zoomValue * 96) / 100;
        });
    }

}

Configure the NatTable instance to

• disable the autoscaling
• use the DefaultMonitorDpiConverter for scaling
• add a zoomChangedListener to react on zoom changes

natTable.setData("AUTOSCALE_DISABLED", true);

natTable.doCommand(new ConfigureScalingCommand(
                    new DefaultMonitorDpiConverter(natTable),
                    new DefaultMonitorDpiConverter(natTable)));

natTable.addListener(SWT.ZoomChanged, e -> {
    // if the zoom level changes we need to reconfigure the scaling
    // converters to ensure that the DPI values are correct
    doCommand(new ConfigureScalingCommand(
            new DefaultMonitorDpiConverter(natTable),
            new DefaultMonitorDpiConverter(natTable)));
});

If you now start your application with -Dswt.autoScale.updateOnRuntime=true the NatTable rendering should update if the applicatoin is moved between monitors with differently configured scalings.

According to @akoch-yatta the above relies on a status that is still under development and might probably change. Therefore the above changes are not yet included in NatTable itself. There are also some places that can't be changed in a simple way, e.g. in the GUIHelper class. For a complete support in NatTable of the monitor specific scaling, there are some more steps to do.

I start this discussion now, to note down the findings so far, and to be able to get updates once the SWT team has a solution released.

[fipro78]

@HeikoKlare @akoch-yatta

I have worked on the monitor specific scaling. I noticed some issues with the 4.36 release that introduced the SVG support. I then updated to the latest 4.38 release and noticed some changes, some things are fixed, and some flaws still exist.

If I start the application with -Dswt.autoScale.updateOnRuntime=true and set natTable.setData("AUTOSCALE_DISABLED", true); (enable autoscaling in general but disable it for NatTable) I get several strange rendering behaviors. Some of them are clear, for example the rendering of dialogs and shells (e.g. NatCombo dropdown) are rendered with incorrect sizes. But as a new Shell does not share any setting from another control like a parent, seems to be the intended behavior.
What seems to be not the correct behavior is when I set the bounds of a Control via Control#setBounds() the size of the control, e.g. a Text, is shown in the correct location with the correct size inside the NatTable as an inline control. So setting the bounds seem to respect the AUTOSCALE_DISABLED setting. But when I get these bounds to position for example the shell of the NatCombo I always get a value that is taking the zoom into account, even though I disabled it for NatTable. I am not sure if this is simply done wrong in my implementation now, or if there is some inconsistency in the DPIUtil usage. The code for the positioning of the dropdown shell is here:

nattable/org.eclipse.nebula.widgets.nattable.core/src/org/eclipse/nebula/widgets/nattable/widget/NatCombo.java

Line 1082 in c10a168

Point textPosition = this.text.toDisplay(this.text.getLocation());

Interestingly it works correct if -Dswt.autoScale.updateOnRuntime=false (of course, there is no autoscaling) or if I keep the autoscaling enabled for NatTable. In that case the positioning is correct.

I therefore decided to try to keep the autoscaling enabled and see how that behaves then. With some modifications this seems to look ok.

If I start the application with -Dswt.autoScale.updateOnRuntime=false or set natTable.setData("AUTOSCALE_DISABLED", true); (so basically disable the autoscaling) the rendering of the SVG images is sharp and looks good even on dynamic scaling. If I enable the autoscaling, the SVG are always rendered blurry. I have seen that there is some work ongoing in the tickets. So maybe this gets fixed in the upcoming release.

I have pushed my work in the monitor_scaling branch. As the high dpi autoscaling seems to be not really stable in the current release (at least not stable enough for NatTable?) but there is quite some work for the upcoming release, I tend to wait with merging my current work related to the autoscaling.

I noticed that there was also an improvement on the getDPI() area, but I think the goal in the long run should be to get rid of it, right?

Maybe you want to have a look at the current status and maybe propose improvements? For example I noticed that in 4.36 the native zoom was available in the data field of Widget, while in 4.38 it is now a public internal field of the class itself. Which actually caused some headache as the above snippet worked in 4.36 in produced incorrect results in 4.38 because of the change from data to nativeZoom field.

Are there any additional changes I need to consider in the future?

[HeikoKlare]

Hi @fipro78, I finally found some time to have a look into you findings. Sorry for the late reply.

I therefore decided to try to keep the autoscaling enabled and see how that behaves then. With some modifications this seems to look ok.

If SWT autoscaling works for you, sticking to it is probably the best you can do. We have been working on making the disablement of autoscaling at the level of individual controls as convenient as possible, but it's conceptually more difficult (and at some places impossible) to make it work as transparent as the general SWT autoscaling itself. One difficulty is the different zooms of controls inside the same shell such that point coordinates (e.g., bounds) are tied to an autoscaled/non-autoscaled context (as you have experienced with the text/combo, more on that below).
I see two major reasons to disable autoscaling for custom controls:

1. You need to render pixel-perfect content and do not want to be influenced by the conversion/rounding issues introduced by SWT's autoscaling and the limited precision. This was not so much an issue in the past when autoscaling basically only meant 100% or 200% (where rounding is less problematic) but became more severe with exact zooms (including 125% etc.) being used. Still, the underlying issues were present already before, just not that severe and thus often unnoticed.
2. You use fine-grained/clipped repaint of dirty areas: if you repaint only small/dirty areas of the control upon content changes, resizes or the like, you will run into severe rendering artifacts with SWT's autoscaling as the coordinates for the regions to refresh do not perfectly fit because of rounding inaccuracy.

The first intended consumer of autoscale disablement at control-level was GEF Classic, which has both these requirements. If I am not mistaken, NatTable does not have either of them (in particular, it does not do a repaint of dirty areas but always renders the whole table, does it?), which is why it may be fine with the existing SWT autoscaling.

I get several strange rendering behaviors. Some of them are clear, for example the rendering of dialogs and shells (e.g. NatCombo dropdown) are rendered with incorrect sizes. But as a new Shell does not share any setting from another control like a parent, seems to be the intended behavior.

When you want make the sizes of different controls fit, you always have to make sure that these sizes are the same in logical points. When you provide a combo dropdown for an autoscale-disabled control in a separate shell, it either needs to be autoscale-disabled as well and can then be sized with the same size as the underlying autoscale-disabled control (which needs to be custom-scaled according to the monitor zoom) or it can be autoscale enabled (using ordinary SWT autoscaling) but then needs to be sized with the size of the underlying control in logical points (i.e., without the zoom manually applied to it).

What seems to be not the correct behavior is when I set the bounds of a Control via Control#setBounds() the size of the control, e.g. a Text, is shown in the correct location with the correct size inside the NatTable as an inline control. So setting the bounds seem to respect the AUTOSCALE_DISABLED setting. But when I get these bounds to position for example the shell of the NatCombo I always get a value that is taking the zoom into account, even though I disabled it for NatTable. I am not sure if this is simply done wrong in my implementation now,

The handling of bounds, sizes and locations of autoscale-disabled controls is a bit complicated, in particular when you have an autoscale-enabled control inside an autoscale-disabled control which is again placed in an autoscale-disabled control. This is common pattern in scenarios like the one you mention (autoscale-enabled shell/composite, then an autoscale-disabled custom control like a table, then an autoscale-enabled edit control such as a text box), which we have specificially seen and solved in GEF Classic as well. I am not sure if in your case the text control is autoscale-disabled or not, which might make a difference regarding which zoom is used.
What doesn't seem correct to me is the control on which you apply the toDisplay conversion. Just from the concept without testing, I would expect this to be (more) correct:

Point textPosition = this.text.getParent().toDisplay(this.text.getLocation());

The location given by text.getLocation() is relative to the parent, so you should transform from the parent coordinate system to the display coordinate system. That may even resolve your placement issues (as the parent may have different autoscale settings and then apply the correct zoom).

If I start the application with -Dswt.autoScale.updateOnRuntime=false or set natTable.setData("AUTOSCALE_DISABLED", true); (so basically disable the autoscaling) the rendering of the SVG images is sharp and looks good even on dynamic scaling. If I enable the autoscaling, the SVG are always rendered blurry. I have seen that there is some work ongoing in the tickets. So maybe this gets fixed in the upcoming release.

Yes, SVG scaling/rendering was heavily improved for the upcoming release. So if we did not miss anything, every GC.drawImage() operation accepting an SVG should now always render the SVG sharply for the desired size.

I noticed that there was also an improvement on the getDPI() area, but I think the goal in the long run should be to get rid of it, right?

It would be great to get rid of that method as it has a quite complex semantics which makes it really difficult to use properly across all the different autoscaling capabilites and modes that have been introduced to SWT. Since for some scenarios the method seems to still be necessary, we tried to clarify its meaning and make aware of the limited usability.

Maybe you want to have a look at the current status and maybe propose improvements? For example I noticed that in 4.36 the native zoom was available in the data field of Widget, while in 4.38 it is now a public internal field of the class itself. Which actually caused some headache as the above snippet worked in 4.36 in produced incorrect results in 4.38 because of the change from data to nativeZoom field.
Are there any additional changes I need to consider in the future?

As pointed out at the beginning of the post, if everything works fine for you without disabling autoscaling, you should avoid the potential hassle with that feature and rather stick to the existing SWT autoscaling support.

The whole autoscaling disablement functionality was rather experimental until now, which is why the used data fields also changed.
If you really need the autoscale disablement at control level, there will be public API for it starting with the 4.39 release. So you do not need to deal with internal data fields anymore but can use documented methods. It also makes more explicit whether autoscale disablement is inherited by child controls or not (which required an additional data value before). The information previously provided via the "native zoom" data / field of a control is now available as a proper shell zoom which you can retrieve via getShell().getZoom(). There are two news entries covering the relevant information:

• Autoscale Disablement API
• Shell Zoom API

Let me know if any information is insufficient or if you need help in adopting the autoscale disablement feature (though I still hope you can completely avoid to use it).

[fipro78]

@HeikoKlare
Thanks a lot for the response. As said, I already thought of not disabling the autoscaling but try to make things work with the platform autoscaling enabled. Which looks ok so far, despite the SVG image rendering of course. I will update the target platform in the branch to the latest development to see how it looks like then.

With regards to the autoscaling I noticed an issue with the Browser: eclipse-platform/eclipse.platform.swt#2974

The Nebula RichTextEditor as embedded editor goes crazy on resizing if Edge is used. Not sure if anybody was already able to have a look. Looks like the event is changing width and height somehow. And there seems to be a rounding issue on scaling. I am currently unsure how to fix this.

[HeikoKlare]

I just took the time to take a deeper look at the resizing issue and responded in the mentioned issue.

[fipro78]

I think I got the most issues resolved. I will respond in the issue once I am done, so it can be closed. Currently it looks like there are several issues, not sure where they originate, but they can probably be worked around in the RichTextEditor.

For getting rid of the Display#getDPI() method I noticed one use case can currently not be resolved. At least I don't find a correct solution. With the Shell#getZoom() method I can get rid of most of the DPI related calculations. But in one place I need to calculate the font size in points from a given pixel value.

int pointSize = Math.round((pixel * (shell.getZoom() / 100f)) * (72f / Display.getDefault().getDPI().x));

I have seen that there is something similar in the Device class. But there is no public API available for this.

I also noticed DPIUtil#mapZoomToDPI() which is also not public API nor is it exposed similar to Shell#getZoom().

Any hints or ideas on this?

[HeikoKlare]

This looks like a situation where you may actually still need the getDPI() method (i.e., one of the reasons why we removed the deprecation again). In particular on Windows, the getDPI() method returns a relevant font "scaling factor" when not using monitor-specific scaling. As I am not completely sure about the semantics of the values involved here (especially the meaning of pointSize which does not seem to refer to SWT's logical points, does it?), so I cannot fully assess if the calculation might be correct or not. It would probably be good to test with monitor-specific scaling disabled at 175% and above, as that combination might break when combining shell.getZoom() and Display.getDPI().
Edit: I found the according code in the Nebula PR, so I will have a look there.