Alternative to Device.getDPI() ?

[Phillipus]

Now that Device.getDPI() is deprecated what is the recommended way to get the current display DPI?

42c3226 and #2872

In our RCP app we call Device.getDPI() like this for scaling fonts depending on OS:

int DPI = Display.getCurrent().getDPI().y;
FontData fd = new FontData("fontname");
float factor = (float)96 / DPI;
int newHeight = (int)(fd.getHeight() * factor);
fd.setHeight(newHeight);

In earlier versions of SWT Device.getDPI() would return different values on Windows depending on scale:

225% = 108 DPI
200% = 96 DPI
175% = 84 DPI
150% = 144 DPI
125% = 120 DPI
100% = 96 DPI

It seems that in recent versions of SWT the DPI on Windows is always returned as 96 so that makes things easier.

But what about Mac? That can be 72 DPI or perhaps something else. What is the recommended way to determine DPI?

[laeubi]

in our RCP app we call Device.getDPI() like this for scaling fonts depending on OS

Should font size not always be "in DPI" already?

What is the recommended way to determine DPI?

I'm not sure why getDPI is deprecated at all at least for printer device they can have different DPI at least so I can only assume it is not recommended to get the DPI for a Display as there is not a single DPI setting but for printers this is not true and might not for other devices.

[Phillipus]

Should font size not always be "in DPI" already?

Differs between Mac and Windows because Mac uses 72 and Windows 96.

[laeubi]

Should font size not always be "in DPI" already?

Differs between Mac and Windows because Mac uses 72 and Windows 96.

What do you mean by "differs", I mean if I have a area of 100x100 points and a font of h=50 points then the DPI should not make a difference (font should fill approximate 50% of my area)

[Phillipus]

What do you mean by "differs", I mean if I have a area of 100x100 points and a font of h=50 points then the DPI should not make a difference (font should fill approximate 50% of my area)

Font(display, "Arial", 12, SWT.NORMAL) will look different on Mac than on Windows display because Mac uses 72 DPI and Windows uses 96 DPI. SWT FontData height is in points (1 pt = 1/72 inch or 1 pt = 1/96 inch) so to compensate for this we use the code above.

[Phillipus]

This is from Grok AI:

In Eclipse SWT, fonts are created using FontData where the height is specified in points (1 point = 1/72 inch).
Despite this absolute unit, the on-screen appearance (pixel height and overall look) of the same point-sized font differs between macOS and Windows due to platform-specific behaviors:

SWT on macOS uses a baseline of 72 DPI for converting points to pixels. On Windows, SWT aligns with the system's default of 96 DPI. This means the same N-point font renders larger in pixels on Windows (N × 96/72 ≈ 1.33× taller) than on macOS, making it appear bigger on Windows.

SWT's FontData specifies font height in typographic points (1 point = 1/72 inch). The actual pixel height on screen depends on the platform's logical DPI (dots per inch) used for scaling:

On Windows (and Linux/GTK), SWT uses a logical DPI of 96. Pixel height ≈ 12 points × (96 / 72) = 16 pixels.
On macOS, Pixel height ≈ 12 pixels (or closer to that before additional HiDPI scaling).

[Phillipus]

In our app a user Windows sets a font on a figure in a diagram, let's say Arial 11. Here's how it looks on Windows:

The diagram is saved and opened by a user on Mac. Here's how it looks:

That's because Mac is using 72 DPI on screen not 96. So we apply the following to compensate:

// Get DPI
int DPI = Display.getCurrent().getDPI().y;
if(DPI != 96) { // Not needed on Windows, but Mac will be 72 (or perhaps something else?)
    FontData fd = new FontData(fontToScale);
    float factor = (float)96 / DPI;
    int newHeight = (int)(fd.getHeight() * factor);
    fd.setHeight(newHeight);
}

We've been doing that for years. So when I see:

@Deprecated
public Point getDPI () {

If something is deprecated it will, at some point, be removed. So I look for "Deprecated, use xyz instead" but I don't see the recommended alternative.

[Phillipus]

Snippet:

import org.eclipse.swt.SWT;
import org.eclipse.swt.graphics.Color;
import org.eclipse.swt.graphics.Font;
import org.eclipse.swt.layout.FillLayout;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;

public class FontTest {
    
    public static void main(String[] args) {
        final Display display = new Display();

        final Shell shell = new Shell(display);
        shell.setText("SWT Test");
        shell.setLayout(new FillLayout());
        shell.setSize(300, 250);
        shell.setBackground(new Color(255, 255, 255));
        
        Font font = new Font(display, "Arial", 11, SWT.NORMAL);
        
        shell.addPaintListener(e -> {
            e.gc.setFont(font);
            e.gc.drawText("Hello World, this is Arial Font 11", 20, 50);
        });
        
        shell.open();

        while(!shell.isDisposed()) {
            if(!display.readAndDispatch()) {
                display.sleep();
            }
        }

        display.dispose();
    }
}

Windows:

Mac:

[Phillipus]

The comment here makes some good points.

[Phillipus]

The Eclipse GMF project also uses Display.getDPI() to calculate font height:

int dpi = Integer.getInteger("org.eclipse.gmf.runtime.draw2d.ui.render.dpi", DisplayUtils.getDisplay().getDPI().x); //$NON-NLS-1$
float fsize = (float) height * (float) dpi / 72.0f;        // display DPI / AWT DPI
height = (int) fsize;

https://github.com/eclipse-gmf-runtime/gmf-runtime/blob/ccc53e5a60bb094fc27554f5fef413ac825693b9/bundles/org.eclipse.gmf.runtime.draw2d.ui.render.awt/src/org/eclipse/gmf/runtime/draw2d/ui/render/awt/internal/graphics/GraphicsToGraphics2DAdaptor.java#L1078-L1080

[laeubi]

That's because Mac is using 72 DPI on screen not 96. So we apply the following to compensate

That's interesting (and a bit unexpected) and of course hinders the goal of SWT to be cross-platform. I already have similar issue with different default font-sizes and the width of table rows what I solved by introducing an em unit.

[akoch-yatta]

@Phillipus Thanks for the issue and the additional information of you use case.
First of alI, I still think deprecating getDPI (in the way it is done in the mentioned PR) is necessary, because you cannot implement a consistent behavior with the current implementation, as the DPI of a Display is not consistent in all scenarios. As it is consistent in Printer, it still makes sense there.

Other than that, we obviously need to have a look into existing usages and how to properly replace them. If there is some additional API necessary for that, we should add it. Thats why we merged it for M1 to raise awareness and either find solutions for everyone or (if necessary) postpone the deprecation until we have solutions.

First, one question from me - do you only use this "correction" of font sizes it in the context of GC @Phillipus?

In general, I had a deeper look into this behavior in SWT today. There is obviously a fundamental difference in the expectation regarding font sizes between Mac and Windows/GTK. What I understand from your description and e.g. what GMF is doing - you want to "break" with that and have equal font size behavior over all implementations. This sounds like a reasonable request in some scenarios, but in my opinion that should be a use case provided by SWT when working with a GC, e.g. by making this behavior configurable in GC.

Another question: extending your Snippet e.g. with drawing a Rectangle with 50pt width and height, I assume it will look quite different between both OS then in regards to the spacing as well, right?

In earlier versions of SWT Device.getDPI() would return different values on Windows depending on scale:

225% = 108 DPI 200% = 96 DPI 175% = 84 DPI 150% = 144 DPI 125% = 120 DPI 100% = 96 DPI

It seems that in recent versions of SWT the DPI on Windows is always returned as 96 so that makes things easier.

If you have a look into the implementation in Windows, you'll see why: the value is based on the autoscale mode, which is still integer200 as default in SWT, but was changed to quarter in Eclipse for some releases. Using integer200 returns completely bogus results, as you see.

[Phillipus]

@akoch-yatta

as the DPI of a Display is not consistent in all scenarios.

On Mac it seems to be always 72. It might not always be 72 so we check it.

First, one question from me - do you only use this "correction" of font sizes it in the context of GC @Phillipus?

All figures are Draw2d figures where the bounds of the figure is in pixels and rendered ultimately in GC with GC.callMethodXXX() and so with fonts it is GC.setFont(font);

extending your Snippet e.g. with drawing a Rectangle with 50pt width and height, I assume it will look quite different between both OS then in regards to the spacing as well, right?

The rectangle is drawn in pixels and they are all the same size on all platforms. The problem comes only with fonts where all we have is the FontData height in points. The points to pixels conversion is therefore different between 96 on Windows/Linux and 72 on Mac. As our users want to see the same pixel font sizes on Mac/Windows I scale accordingly. We absolutely need to do this, and have done so for the last 15 years in our app.

[akoch-yatta]

@akoch-yatta

as the DPI of a Display is not consistent in all scenarios.

On Mac it seems to be always 72. It might not always be 72 so we check it.

I meant the behavior on windows with that comment.

First, one question from me - do you only use this "correction" of font sizes it in the context of GC @Phillipus?

All figures are Draw2d figures where the bounds of the figure is in pixels and rendered ultimately in GC with GC.callMethodXXX() and so with fonts it is GC.setFont(font);

so, you don't do any correction with it related e.g. to the font of a Control like a Button, right?

extending your Snippet e.g. with drawing a Rectangle with 50pt width and height, I assume it will look quite different between both OS then in regards to the spacing as well, right?

The rectangle is drawn in pixels and they are all the same size on all platforms. The problem comes only with fonts where all we have is the FontData height in points. The points to pixels conversion is therefore different between 96 on Windows/Linux and 72 on Mac. As our users want to see the same pixel font sizes on Mac/Windows I scale accordingly. We absultely need to do this, and have done so for the last 15 years in our app.

Yes, that is what I meant: without your correction, the relation of font to rectangle would be very different.

So my conclusion is still: You want to draw fonts (e.g. with a point size of 10) always with the same font size in pixel on all OS. This is currently corrected in your (and probably) other application on client side by utilizing getDPI. So two options in my opinion:

1. Provide a new similar API that is reliable Display#getDpi in Windows in very unreliable but change its behavior would break a lot of workaround, which is not an option in my opinion.
2. Provide a way to enable a configuration for this use case for GC and do this adaption transparently in the GC implementation for cocoa, so consumers do not do this conversion at all.