Provide Monitor#getDPI()

[laeubi]

Display#getDPI states

Caution: this method may yield unexpected results when using multiple monitors. This method returns a value based on the primary monitor DPI on startup (depending on the OS).

but it is hard to guess what to use instead, eg Monitor#getZoom exits but it is unclear how this has to be used.

Printer on the other hand has getDPI() returning the DPI of the printer, so it seems natural that Monitor would have one as well if DPI differs per monitor.

[laeubi]

@HeikoKlare what do you think? Background is I want to print a control, but if the device dpi and printer DPI differs then this gives way to small results.

[HeikoKlare]

From a technical perspective, every monitor has a DPI (other than the concept of the SWT Display), so it should be technically possible and semantically "correct" to add a Monitor#getDPI() method.

One difficulty is that the current Monitor implementation is common for all platforms, but a getDPI() method would probably require that class to become OS-specific. Nothing unsolveable, but might come with some issues regarding API tooling or the like.

My only question would be about the actual necessity for having such a method. Can you explain or exemplify how you want to relate monitor and printer DPI for printing a control? Is the goal to have a virtual/printed document that contains a screenshot of the control which (in physical units) is equal to the original one? Or is only about printing the control in a "reasonable" size?

[laeubi]

One difficulty is that the current Monitor implementation is common for all platforms, but a getDPI() method would probably require that class to become OS-specific. Nothing unsolveable, but might come with some issues regarding API tooling or the like.

What I could think of (as Display and Monitor are in the same package) would be to actually have Monitor#getDPI calling package private method Display#getDPI(Monitor) and as Display is already OS specific...

Is the goal to have a virtual/printed document that contains a screenshot of the control which (in physical units) is equal to the original one?
Or is only about printing the control in a "reasonable" size?

Yes this describes it quite good I think. The complication comes from that Printer (obviously) can have different DPI than screen (and similar with new PDFDocument that always has 72 DPI).

So lets say I want to make a hard copy of the screen or a widget (lets say a StyledText or Browser) then it is not really possible to reliable layout it, for example if I want a usual function like print it with the full width of the page. Printer has Printer.getClientArea() but even if that is equal to what Control#getSize returns the actual printed "image" is much smaller.

I currently try to sort that out but for me it seems sooner or later one needs to calculate a scale factor that includes the DPI used to paint "on screen" (=Monitor) versus "on device" (=Printer or PDFDocument).

[HeikoKlare]

What I could think of (as Display and Monitor are in the same package) would be to actually have Monitor#getDPI calling package private method Display#getDPI(Monitor) and as Display is already OS specific...

That sounds like a good idea.

I understand the issue and I don't see a good solution with what is currently available either. Since a Monitor.getDPI() is in my opinion semantically reasonable anyway, I think adding such a method is totally fine if it solves the issue. Even if we found a different solution later on, having and keeping that method should not be problem.

[laeubi]

@HeikoKlare thanks for the feedback, I now have digged deeper into this and think we actually can and should provide a Display#getDPI on Windows (other platforms as well) but with a slightly more advanced description and then the Monitor#getZoom() finally makes sense (at least to me) and a further method is not needed but maybe just as a convenience and then can even be implemented os independent.

To illustrate this better I have created this snippet:

• Add a new snippet to demonstrate drawing to different devices #3065

So my understanding is (please correct me if I'm wrong):

• If I have a control (e.g. a Shell, or a Button) and I call getSize() on it (or call setSize(...)), the value returned is independent of monitor zoom, what might also change over time.
• Then we have different Devices (most notably Display and Printer, hopefully soon PDFDocument) where I can create a GC for and then perform drawing operations. Again here, if a draw a box with size.x/2, size.y/2 we expect it to cover 1/4 of the drawing area independently from monitor zoom.
• Consequently there is an (inherit) DPI value that is valid on 100% zoom and relates to one "unit" of things we usually measure as an integer in SWT (e.g. GC.drawLine, setSize(...), getBounds(), ...)
• This unit is then scaled up depending on Monitor Zoom (now dynamically) on Windows but is static on other OS (Linux/Mac)

From that I draw the following conclusions:

1. Display#getDPI should not return any maybe "native" DPI of an actual monitor or setting, but exactly this base unit so if I set the size of a control on a 100% monitor to that value it is at best exactly one inch high / wide. On 200% zoom it will be two inch and so on.
2. If I want it to be always one inch high / wide, I need to fetch the Monitor of the control and adjust my values accordingly (and possibly listen to DPI changes to adapt)
3. If I want a certain absolute size (e.g. something drawn on a Canvas should be 10 mm high/large) I need to take the DPI into account from the device that I created the GC from (and possible the monitor zoom if I want to cancel out the effect of monitor zoom)
4. If I draw on different Devices (e.g. a printer) I can use the same drawing code independent from the actual DPI setting of that Device and e.g. getClientArea() must return values in the base unit what mean if I paint a 100x100 box draw a box with clientArea.w/2, clientArea.h/2 it will always cover 1/4 of the available drawing area.

Does this sounds reasonable to you? If yes I would try to adjust the javadoc of Display#getDPI in this regards to explain how the value and the monitor zoom relates and how one can draw in absolute values (what of course is important for printing for example).

[HeikoKlare]

At a glance, the conclusions sound reasonable to me. But I have to admit that the Device.getDPI() implementation got so broken with the different stages of HiDPI support that it produces headaches everytime we try to understand it and that I would need more time to dig into it again.

I am not in favor of messing up with that method again and I don't think it's something broady useful at all. We have repeatedly broken it in the recent years and just adapted it to (1) be consistent with all previous use cases, auto-scale configurations, changes of primary monitor zoom and the like and (2) yield a resonable result when using monitor-specific scaling on Windows.
The method got a specific meaning throughout the last years, particularly related font scaling due to the former mixture of font zoom and auto-scaling zoom when not using monitor-specific scaling or more specifically the auto-scale mode "integer".
We have already clarified the contract in that regard:

• Undeprecate Device#getDPI & clarify getDPI contract #2962

and also wrote a news for it:

• https://eclipse.dev/eclipse/markdown/?f=news/4.39/platform_isv.md#clarification-of-devicegetdpi-contract

In my opinion, the situation can only become better if we remove all the complex auto-scaling configurations as otherwise a method like Display.getDPI() will always be hard to comprehend if it is so heavily dependent on the currently used configuration.

[laeubi]

We have already clarified the contract in that regard

What is (in my opinion) already good as it says

With this release, the method is adapted in Windows to always return the system base DPI (which is currently 96) when monitor-specific scaling is enabled

As you mentioned the previous behavior was quite ... well unexpected sometimes. But that now seem to match whats happening on Linux (96 DPI) / Mac (72 DPI) anyways (one logical DPI see also here). So I need to check in what regards Shell#getZoom() differs from Monitor#getZoom() (or maybe its just a shorthand?).

For simplicity we can assume that we assume the auto-scaling is enabled, and getDPI always return 96, then on a 200% windows the actual "system DPI" would be effectively 2*96 = 192 as all control are painted with double size correct?

[laeubi]

@HeikoKlare I was now able to visualize the effect here:

• Enhance Snippet391 to allow direct calling of print method #3068