On 25.11.16 17:08, Semyon Sadetsky wrote:
Then JDK-8013116 was fixed the request for specification update was
created: https://bugs.openjdk.java.net/browse/JDK-8033128
Different coordinate system simply means different coordinate origins.
This is the most natural behavior for the robot created for certain
screen.
And if both screens have the same coordinate system simply means that
they have same coordinate origins.
They may share the same extended screen coordinates but have different
origins.
If the same coordinate system is shared by both screens, means that each
point passed to the robot will be related to the(0,0). It is not
necessary the (left/top) point of the screen because the screen itself
can be shifted from the (0,0)/
If you switch off Xinerama on Linux, not sure that this is well
supported by default desktop shell, anyway, then you can run an app on
the second monitor using DISPLAY=:0.1.
If this app creates robot for the current screen it acts in the 2nd
screen coordinates according to the spec.
The whole application will use the coordinate system of the second
monitor, because this is separate standalone screen.
The same app can be run on the usual extended desktop and then moved to
the second screen. In this case, the robot created for the current
screen should act in 2nd screen coordinates as well, otherwise behavior
of the app would be different and depend on the native platform
configuration.
The robot should always use the coordinate system of the screen, in the
same way as TopLevel windows use it.
I didn't see a desktop within the OSes supported by JDK9 where multiple
screens are treated as a separate displays rather then one extended
desktop.
Such configurations exists, even if default configs supported by
Oracle have Xinerama does not mean that it was not supported in past,
and is not supported by OpenJDK in general.
It seems JDK-8013116 should be reworked to correspond to the current
state of multiscreen concept on the supported platforms.
--
Best regards, Sergey.
