This post was updated on .
Yes, it shall set the used surface scale of the existing or not yet existing window.
For the latter, we have to track it.
On OSX, we do set the surface scale ourselves having a high-dpi monitor,
if you would not, you would get a low or high density surface (err .. guess low density as default).
So, depending on he desktop setting, the user may get what is expected.
But we have to programmatically set the surface scale here,
hence separated scale of window-coordinates (low 71 or 96 dpi old fashioned pixel surface)
and the actual surface-coordinates for the pixels.
The MacOS logic should act as follows:
IF reqSurfaceScale = -1 == auto, use the default (desktop) setting -> high-dpi if available for examples
IF reqSurfaceScale > 0 (i.e. user requested) then try to use it if supported.
Now, this logic shall also work for Windows or X11,
with the "only" difference that the underlying surface-dimension always equals to the actual monitor density (high-dpi),
since the GDI or X11 toolkit only knows pixels.
Hence the windows coordinates must be multiplied by this imaginary-scale to get the desired real size ;-)
So yes, on your Windows or X11 a 125% scale shall bloat up the surface-dimension (in pixels)
and hence bloat up the window pixel-size .. and, imagine you work on a like 96 dpi monitor, the window size as well.
THIS adjustment for Windows and X11 has only one goal,
i.e. to adjust old applications window size to new high density monitors (make 'em readable, bloat pixel volume up).
Of course, if your eyes are no more as good, you can also use it to scale up the stuff as well.
Edit: I.e. you can't increase the actual monitor DPI (duh), so a higher 'scale' or multiple of the 96dpi leads to bigger
surface sizes assuming 96 dpi is '1'. On a 2*96dpi monitor one would need to set the scale to 2 for 1:1 pixels,
now this starts to confuse me myself and I shall not look so deep in this UI un-metric abyss ;-)
For modern applications, eg using NEWT, such concept is not required as we can read the monitor metrics
w/ DPI and hence scale the application proportional to the display w/ DPI etc.
No scaling to a 96dpi multiple is required nor really welcome IMHO.
Edit: Think about HTML/CSS layout, we just would want to scale the UI proportionally and may just use
the mighty em-size. This concept is currently also used in GraphUI (tada) and you can resize your window
where the elements are simply resized automatically in a proportion fashion (the goal).
Here we just would use scaled Group Container containing elements and Groups, with elements
of a normalized size '1' (em size) scaled by their container etc.
Pixel counting is no more.
For AWT usage it is essential to know the scale factor to get the expected pixel volume so to speak :)
For this application, the reqPixelScale shall have no meaning indeed and shall always work
by assuming it is in auto (-1) setting.
EDIT: AFAIK, the reqPixelScale should be used here in case the AWT window is not yet realized?
Meaning the AWT destination will request the new scale?
But again, I would need to dive into this code once again to resolve it with Windows/X11 in mind
to cooperate well w/ AWT.
If lucky I might get a little funding for that .. but one day will fix it anyways (or you do this).
In the meantime .. enhancing the GraphUI CSS alike layout ... (reason why I was also thinking about this issue here as of late).