Hi Sergey,
Yes, waitForIdle works 99% of the time. But, there is no deterministic
guarantee, that the previous set of operations have completed before the next
set of operations can begin.
I have not seen Toolkit.sync() being called inside waitForIdle, although I
doubt if even that leads to a 100% guarantee.
Also, I found the below explanation from the documentation of the realSync
function, which itself mentions a caveat:
" * <p> Notice that realSync isn't guaranteed to work if recurring
* actions occur, such as if during processing of some event
* another request which may generate some events occurs. By
* default, sync tries to perform as much as {@value #MAX_ITERS}
* cycles of event processing, allowing for roughly {@value
* #MAX_ITERS} additional requests.
*
* <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.
waitTillShown() also just sleeps for 100ms, which is not a guarantee that the
operation on the other thread has completed.
Hope this clarifies.
Thanks,
Krishna
-----Original Message-----
From: Sergey Bylokhov
Sent: Saturday, January 20, 2018 5:20 AM
To: Krishna Addepalli <[email protected]>; [email protected]
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.
