On Mon, 9 Nov 2020 04:04:09 GMT, Prasanta Sadhukhan
wrote:
>> Please review a test fix for an issue seen where robot image capture is
>> wrong if screen scale factor is more, which could result in button or frame
>> to move out of captured dimension of 300,300.
>> Fixed by setting uiScale=1
On Sat, 7 Nov 2020 23:08:18 GMT, Sergey Bylokhov wrote:
>> but 300x300 is set in frame setSize..if I use frame getBounds instead of
>> already set 300x300, that will not be right, according to me...What if
>> getBounds() has some bug (in some platform) and return some other
>> width/height
> Please review a test fix for an issue seen where robot image capture is wrong
> if screen scale factor is more, which could result in button or frame to move
> out of captured dimension of 300,300.
> Fixed by setting uiScale=1 in the test which can still reproduce JDK-7154030.
> Mach5 job has
On Sat, 7 Nov 2020 14:33:42 GMT, Prasanta Sadhukhan
wrote:
> but 300x300 is set in frame setSize..if I use frame getBounds instead of
> already set 300x300, that will not be right, according to me...
The test should set the size 300,300 to the frame and then request and use the
real bounds
On Sat, 7 Nov 2020 09:02:02 GMT, Sergey Bylokhov wrote:
>> Prasanta Sadhukhan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> use getBounds()
>
> test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 96:
>
>> 94:
On Wed, 4 Nov 2020 14:38:06 GMT, Prasanta Sadhukhan
wrote:
>> Please review a test fix for an issue seen where robot image capture is
>> wrong if screen scale factor is more, which could result in button or frame
>> to move out of captured dimension of 300,300.
>> Fixed by setting uiScale=1
On Thu, 5 Nov 2020 11:35:20 GMT, Prasanta Sadhukhan
wrote:
>> GC.getBounds() and Toolkit.getScreenSize() return the same bounds, but the
>> bounds of the screen, not the window bounds.
>
> I guess we need the screen bounds only, no? I guess by window bounds, u mean
> frame bounds which is
> Please review a test fix for an issue seen where robot image capture is wrong
> if screen scale factor is more, which could result in button or frame to move
> out of captured dimension of 300,300.
> Fixed by setting uiScale=1 in the test which can still reproduce JDK-7154030.
> Mach5 job has
On Thu, 5 Nov 2020 11:30:21 GMT, Sergey Bylokhov wrote:
>> Modified to use bounds.
>
> GC.getBounds() and Toolkit.getScreenSize() return the same bounds, but the
> bounds of the screen, not the window bounds.
I guess we need the screen bounds only, no? I guess by window bounds, u mean
frame
On Wed, 4 Nov 2020 14:35:35 GMT, Prasanta Sadhukhan
wrote:
>>> The locx,locy calculation to move to center of screen is done intentionally
>>> as we need to use the same coordinate in robot to capture the screen
>>
>> You can use locx/loxy intentionally to move the window, but you can't use
On Wed, 4 Nov 2020 06:21:26 GMT, Sergey Bylokhov wrote:
>> I know setLocationRelativeTo(null) will move to center of screen but I
>> needed the coordinate for robot interaction.
>> The locx,locy calculation to move to center of screen is done intentionally
>> as we need to use the same
> Please review a test fix for an issue seen where robot image capture is wrong
> if screen scale factor is more, which could result in button or frame to move
> out of captured dimension of 300,300.
> Fixed by setting uiScale=1 in the test which can still reproduce JDK-7154030.
> Mach5 job has
On Wed, 4 Nov 2020 02:42:16 GMT, Prasanta Sadhukhan
wrote:
> The locx,locy calculation to move to center of screen is done intentionally
> as we need to use the same coordinate in robot to capture the screen
You can use locx/loxy intentionally to move the window, but you can't use it in
a
On Tue, 3 Nov 2020 18:38:15 GMT, Sergey Bylokhov wrote:
>> Prasanta Sadhukhan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove uiScale
>
> test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 96:
>
>> 94:
On Tue, 3 Nov 2020 16:32:07 GMT, Prasanta Sadhukhan
wrote:
>> Please review a test fix for an issue seen where robot image capture is
>> wrong if screen scale factor is more, which could result in button or frame
>> to move out of captured dimension of 300,300.
>> Fixed by setting uiScale=1
On Fri, 30 Oct 2020 11:42:53 GMT, Prasanta Sadhukhan
wrote:
> Please review a test fix for an issue seen where robot image capture is wrong
> if screen scale factor is more, which could result in button or frame to move
> out of captured dimension of 300,300.
> Fixed by setting uiScale=1 in
> Please review a test fix for an issue seen where robot image capture is wrong
> if screen scale factor is more, which could result in button or frame to move
> out of captured dimension of 300,300.
> Fixed by setting uiScale=1 in the test which can still reproduce JDK-7154030.
> Mach5 job has
On Mon, 2 Nov 2020 12:50:22 GMT, Prasanta Sadhukhan
wrote:
>> Then please double-check that the test will pass after the fix on HiDPI
>> screen. Not sure that -Dsun.java2d.uiScale=1 affects such usecase.
>
> Since mach5 systems are mostly macmini, where it initially failed, and the
>
On Mon, 2 Nov 2020 12:19:06 GMT, Sergey Bylokhov wrote:
>> It was reported in macmini (probably connect to hidpi screen) and iMac (I
>> guess having hidpi screen).
>> Also, I have seen mach5 job failing on windows too.
>> I have posted failing mach5 jobs in JBS.
>
> Then please double-check
On Sat, 31 Oct 2020 11:06:52 GMT, Prasanta Sadhukhan
wrote:
>> test/jdk/javax/swing/JComponent/7154030/bug7154030.java line 55:
>>
>>> 53: * @build Util
>>> 54: * @build ExtendedRobot
>>> 55: * @run main/othervm -Dsun.java2d.uiScale=1 bug7154030
>>
>> The "sun.java2d.uiScale" does not
On Sat, 31 Oct 2020 03:19:40 GMT, Sergey Bylokhov wrote:
>> Please review a test fix for an issue seen where robot image capture is
>> wrong if screen scale factor is more, which could result in button or frame
>> to move out of captured dimension of 300,300.
>> Fixed by setting uiScale=1 in
On Fri, 30 Oct 2020 11:42:53 GMT, Prasanta Sadhukhan
wrote:
> Please review a test fix for an issue seen where robot image capture is wrong
> if screen scale factor is more, which could result in button or frame to move
> out of captured dimension of 300,300.
> Fixed by setting uiScale=1 in
Please review a test fix for an issue seen where robot image capture is wrong
if screen scale factor is more, which could result in button or frame to move
out of captured dimension of 300,300.
Fixed by setting uiScale=1 in the test which can still reproduce JDK-7154030.
Mach5 job has been run
23 matches
Mail list logo
