One interesting point to note that makes one concern seem less
compelling in a practical sense:
On 2/17/2015 5:27 PM, Jim Graham wrote:
To get an idea of the kinds of problems we might encounter when trying
to translate the screens into "virtual coordinates", consider that the
default layout of linearly placing all screens next to each other is
easy to translate (though if one screen doesn't "divide out" evenly then
some of the locations might be non-integers). But, consider a 3x3 grid
of displays (i.e. 9 monitors in a square grid layout). If they are
identical then the layout would be a perfectly aligned grid. If the
middle screen has double (or half) the resolution of the others then we
have to either have it float in the middle of a "virtual size" space
that is too large for its dimensions, or have it overlap the 8 screens
around the outside, or push the 8 screens around the outside away from
each other so that they no longer touch. Since the user laid the
screens out in pixels in the Control Panel UI, they believe that they
may have created a perfect grid, but we will have to present an
imperfect grid to the JavaFX program if we want to maintain the illusion
that FX Screen object sizes are scaled. Even worse, the adjustments we
have to make would be heuristic and depending on what we choose it might
break what they wanted to achieve, or it might not matter, it depends on
what they were thinking and what we independently decided as to how to
best represent it.
It is interesting to note that, in practice, this case would represent
frustration for the user dealing with Windows before (s)he even tries to
run a program.
If the monitors look nice and grid-like on (or hovering above) their
desk, and if they all have the same resolution, then they'll look nice
and grid-like in the Windows CP. And, they'll all have the same DPI
(unless one monitor has a broken EDID chip that reports a bad physical
size), and our adjustments will be fine since all bounds will be divided
by the same number. (Though, note that the issue with non-integer sizes
still remains here as it does with single-monitor and linear-layouts.)
If one of the monitors has a different resolution (but is identical in
physical size), then the user will feel frustration in trying to get
that physical layout to be represented in the Windows CP. The CP will
want to show that Hi DPI monitor as twice the size of the other little
rectangles since it has twice the number of pixels, and so the grid that
the user sees in the CP won't "fit". It's hard to say what that user
will do in response to that frustration, but when the pixel dimensions
get to our code and we try to make sense of it in a virtual DPI world,
our fumblings may not make it any worse than the Windows CP layout
already made it, or it may be worse, but the user will have already
embraced that frustration just trying to get a nice layout in the CP.
If we reverse this and say that all of the monitors have the same pixel
resolution and one of them is twice (or half) the physical size of the
others, then they may lay out nicely in a grid in the CP since that is
only concerned with their pixel sizes. But the user is not going to
have a nice grid sitting in front of them in the Real World(tm) with the
actual monitors. Our attempts to fudge what looks like an even grid in
the CP may not match what they see in front of them on their desk, but
would a user really want a grid of unmatched physical-sized monitors in
front of them?
So, in trying to come up with a practical scenario where the user has a
nice layout of monitors in front of them, and they are happy with
representing that layout in the CP, and we then mangle it in trying to
translate it into virtual coordinate Screen objects - it's a theoretical
case so far...
...jim
