<AWT Dev> [9] Review request for 8169133: This time, on Windows: java/awt/Robot/SpuriousMouseEvents/SpuriousMouseEvents.java

[Sergey Bylokhov]

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.