Hi All, I have verified this test by running on Krishna's machine which has windows 10 build 1703 and found that the test is falsely passing there as well. So we can safely say that Windows 10 build 1703 as a "fall creators" build.
Sergey, we have a floating point dpi scale(dpi value/96) and we use it to scale down and up to convert from user space to device space and vice versa. This code is present at awt_Win32GraphicsDevice.cpp. In this code if you see we use clipRound() with ceil() function. Since there float to int involved with ceil operation may cause + or - 1 pixel variation in it's value I think. Please correct me if I am wrong here. Since there is an issue with windows 10 build 1703 and also the original fix is mac specific, I think my test fix to keep it specific to mac is the right decision to make. Please correct me if I am wrong here. Thanks and regards, Shashi -----Original Message----- From: Sergey Bylokhov Sent: Thursday, March 1, 2018 2:23 AM To: Shashidhara Veerabhadraiah <shashidhara.veerabhadra...@oracle.com>; Krishna Addepalli <krishna.addepa...@oracle.com>; awt-dev@openjdk.java.net Subject: Re: <AWT Dev> [11] JDK-8196017: java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails On 27/02/2018 07:51, Shashidhara Veerabhadraiah wrote: > Threshold is added because I think it is quite possible especially with > hidpi(fractional) since convert back and forth from user space to device > coordinates which typically results in plus or minus 1 pixel > correction(because of division or multiplication). The bug link contains the > call stack where it is reported as (29, 29) as the location and hence the > test fails. If we have an incorrect conversion to/from device space somewhere, then we should check the reason of this bug instead of adding some threshold to the test. -- Best regards, Sergey.
