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

[Krishna Addepalli]

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 <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.