<Swing Dev> [11][JDK-8176512][TEST_BUG] add a minimal delay to java/awt/Paint/bug8024864.java

[Krishna Addepalli]

Hi Sergey,

"It does not guarantee but this wait + waitForIdle() should be enough."
If it is not guaranteed, how can we say it is enough? 


"Take a look to the code which generates the OPEN_EVENT used in the fix(see Window.show()).
It is posted without relation to the native peer:"

This is incorrect, since before posting the OPEN_EVENT, there is a "super.show()" call which ultimately leads to AwtComponent::_Show function in awt_Component.cpp, which actually posts a message to show the window.

Also, before OPEN_EVENT, ComponentShown event is also posted(if there are active listeners to the component) which also seems to be coming from native side.
So, I think it is more appropriate to rely on OPEN_EVENT or even ComponentShown event, rather than having to use wait.

Thanks,
Krishna

-----Original Message-----
From: Sergey Bylokhov 
Sent: Monday, January 22, 2018 10:09 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> [11][JDK-8176512][TEST_BUG] add a minimal delay to java/awt/Paint/bug8024864.java

On 19/01/2018 20:38, Krishna Addepalli wrote:
>       * <p> For example, requestFocus() generates native request, which
>       * generates one or two Java focus events, which then generate a
>       * serie of paint events, a serie of Java focus events, which then
>       * generate a serie of paint events which then are processed -
>       * three cycles, minimum. "
> 
> All I have done in the test case is to ensure that it runs consistently on all types of machines and platforms.

As described above waitForIdle() may fail if there are kind of events recursion. But this bug is different.

> 
> waitTillShown() also just sleeps for 100ms, which is not a guarantee that the operation on the other thread has completed.
> Hope this clarifies.

It does not guarantee but this wait + waitForIdle() should be enough.

Take a look to the code which generates the OPEN_EVENT used in the fix(see Window.show()).
It is posted without relation to the native peer:
==========
1) EDT: Window.setVisible()->Window.show()->Window.postWindowEvent()->
barrier.await();
2) Main: blocked by barrier.await();

So your code waits when the setVisible() and some additional event
(OPEN_EVENT) will be dispatched by EDT.

==========
The usage of waitForIdle() should produce similar result:

1) EDT: Window.setVisible()->Window.show();
3) Main: post dummy event to EDT->waitLock.notifyAll();
2) Main: blocked in SunToolkit.waitForIdle(final long timeout) by waitLock.wait();

The old code waits when the setVisible() and some additional event
(dummy) will be dispatched by EDT. But it also flush the native queue.

So it is still unclear why waitForIdle does not work.

> 
> Thanks,
> Krishna
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Saturday, January 20, 2018 5:20 AM
> To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
> swing-dev at openjdk.java.net
> Subject: Re: <Swing Dev> [11][JDK-8176512][TEST_BUG] add a minimal 
> delay to java/awt/Paint/bug8024864.java
> 
> On 18/01/2018 19:39, Krishna Addepalli wrote:
>> Yes you are right, that waitForIdle() will make sure that all the events will be processed on EDT. However, lets say the last event on the queue takes sometime to process, then, syncNativeQueue could return true, since there are no more events generated on the queue, and the waitForIdle could return.
>> For example, the event on the EDT could be waiting for a network operation to complete, and till such time it might not generate any more events. But, there is a high chance that, while it is waiting, that thread could get swapped by another thread. If that thread tries to access the so called response from the network immediately, it won't be able to get it, since the other thread has not finished getting it.
>> Similarly, when there is a paint event, there is a small possibility that the EDT thread might get swapped out before it could draw its contents to the screen, and if the main thread accesses the screen immediately, it could get wrong results. This is what would have happened in OEL, for this test case.
> 
> This situation should also be covered by the Toolkit.sync() which is called inside waitForIdle(); Since this test additionally waits 100 ms in waitTillShown() its is strange why waitForIdle() does not work.
> 
> --
> Best regards, Sergey.
> 


--
Best regards, Sergey.