Hi Alexandr,
Thanks for investigating the behaviors.
With respect to using LOGPIXELSX or Y, these methods are used to scale
both horizontal and vertical measurements so we really should have 2
scale values and rescale methods, one for horizontal use and one for
vertical...
...jim
On 1/29/2016 10:41 AM, Alexandr Scherbatiy wrote:
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8076545/webrev.03
- LOGPIXELSX is changed to LOGPIXELSY
On 11/16/2015 1:43 PM, Jim Graham wrote:
Note that LOGPIXELSY is global and static between reboots so it
doesn't really matter which monitor is used to get the value.
Also, the issue is that the measurements are in pixels, so if we
convert them into a resolution independent measurement then the rest
of the scaling in the AWT/2D will be correct regardless of any given
monitor's resolution. We just have to make sure the "de-pixelization"
of the measurement is an apples-to-apples calculation.
The question in my mind is whether the values they get from
GetTheme*() and SPI_GETNONCLIENTMETRICS are relative to LOGPIXELSY, or
the more recent Per-Monitor aware DPI APIs, or ...? It would be
interesting to see what happens to those values when you change the
DPI settings on Windows 8.1 and not reboot. If they stay constant
until you reboot then LOGPIXELSY on the main screen would be the value
to use to de-scale them...
I tried to use the "Change the size of all items" slider on Windows
8.1 without rebooting.
GetDpiForMonitor() returns the updated DPI values: 192, 144, 96
LOGPIXELSY returns unchanged values: 192, 192, 192
SystemParametersInfo(SPI_GETNONCLIENTMETRICS,...) returns unchanged
NONCLIENTMETRICS
GetThemePartSize() returns unchanged theme part sizes
It seems that theme part sizes behave in the same way as the
LOGPIXELSY in this case.
Thanks,
Alexandr.
...jim
On 11/16/2015 12:51 PM, Phil Race wrote:
That seems better. But one more question to get a point clarified.
You are using getDesktopWindow() which is for the primary monitor.
I assume that the 'inversion' results in the value being used to be
independent
of the monitor in a multi-mon situation and so when we move to a 2nd
monitor
that inverted size remains valid ?
If so looks good to me.
-phil.
On 11/16/2015 06:07 AM, Alexander Scherbatiy wrote:
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8076545/webrev.02
- round is used instead of ceil
- inverted scales are used
Thanks,
Alexandr.
On 10/30/2015 10:40 PM, Jim Graham wrote:
In this case round may be better. ceil() is more for cases where you
needed "at least X amount of room", but I don't think a font size is
an "at least this much" kind of case.
Also, I've been toying with the idea that use of ceil() and floor()
in any DPI-adjustment equations should really be "ceil(val -
epsilon)" or "floor(ceil + epsilon)" for some small value of epsilon
chosen just large enough to prevent various round-off errors from
affecting the outcome. One idea is for 1/256 as the value of epsilon
since that could equate to the smallest measurable difference in
terms of alpha or interpolation results (or 1/512 for "half the
smallest quantum")...
...jim
On 10/29/15 1:36 PM, Phil Race wrote:
size->cx = (int)ceil(size->cx / scale);
So if size->cx / scale works out to be 12.0001 you will round it up
to 13?
Can you check what pixel size windows gives you in such a case ?
I'd be a little surprised if they did that rather than round.
Is the SetFontProperty that does not accept a scale parameter still
used
somewhere ?
-phil.
On 10/29/2015 04:53 AM, Sergey Bylokhov wrote:
On 17.07.15 16:27, Alexander Scherbatiy wrote:
- Sergey's point about multi-mon should be checked out.
Windows 8.1 has option "Let me choose one scaling level for
all my
displays".
If I unset it I am able to change the size of all items.
However,
the DPI which returns GetDPIForMonitor is still 2 on HiDPI
displays.
This version looks fine, but I am sure it can be double checked on
windows 10 at some moment as well.
