On 11/7/19 8:22 pm, Prasanta Sadhukhan wrote:
OK. I will also try with more iterations on 18.04. But, one thing is test is 
calling removeNotify,addNotify which are not supposed to be called directly 
from programs. Shouldn't we use allowable APIs maybe setVisible(false), 
setVisible(true)?
BTW, I tried with 100 iterations on local ubuntu18.04 and it passed and I think 
mach5 system is also 18.04, so not sure why it will fail there.

Probably your local system too fast or too slow compared to the mach5 system.


Regards
Prasanta


Regards
Prasanta
On 08-Nov-19 2:42 AM, Sergey Bylokhov wrote:
Hi, Prasanta.

I think that the test passed after the fix is because it does not have enough 
time to update
the location of the Frame by the native callback.

Before the fix we have this sequence of calls:
 1 Sets the bounds of the frame(this bounds are cached in the frame and 
returned by getX/getY)
 2 Make the frame visible
 3 Wait while the callback from the native change the location of the frame 
cached at step 1
 4 Check the coordinates
 5 Destroy/Recreate the peer
 6 goto step  3

After the fix:
 1 Sets the bounds of the frame(this bounds are cached in the frame and 
returned by getX/getY)
 2 Make the frame visible
 3 Check the coordinates cached at step 1
 4 Destroy/Recreate the peer
 5 goto step  3

So actually the new test did not check location of the frame but check the 
values cached in the Frame object.


On 11/6/19 3:57 am, Prasanta Sadhukhan wrote:
Hi All,

Please review a fix for an issue where it is seen the frame location is 
sometimes wrong in mac on mach5 headful nightly run.

It seems to be a timing issue as it shows 10 frames by calling 
frame.removeNotify(),frame.addNotify() repeatedly, which by the way are not 
supposed to be called by programs directly.

Proposed fix is to make not to make thread sleep every time 
removeNotify,addNotify is called so that there is no delay. I have ran mach5 
job (in JBS) for 3 consecutive runs on all 3 platforms and they pass.

Bug: https://bugs.openjdk.java.net/browse/JDK-8233703

webrev: http://cr.openjdk.java.net/~psadhukhan/8233703/webrev.0/

Regards
Prasanta






--
Best regards, Sergey.

Reply via email to