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

[Krishna Addepalli]

Hi Sergey,

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.

Thanks,
Krishna
-----Original Message-----
From: Sergey Bylokhov 
Sent: Friday, January 19, 2018 8:41 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 18:36, Krishna Addepalli wrote:
> Here is my understanding of waitForIdle() - it ensures that all the events on the EDT are pushed, and it has a huge wait time of 10seconds, which should mostly guarantee that there are no pending events on the EDT till the function is executed. And it mostly works on all platforms. The test case failed on OEL, whereas it passed on Windows and Linux. I haven't checked for Mac, but most likely it would work there too.
> The testcase in question tries to paint the window, and then picks the color from a particular location on screen. The function bug8024864::showTestUI has frame.setVisible(true) as its last statement, which should ultimately generate a native paint event. Now waitForIdle will ensure that, that event has been posted, but paint/repaint will involve some work down the OS level. Now, it could be possible that, the scheduler might choose to suspend the EDT thread and run the main thread, which checks for the pixel color on the screen and it might fail.

waitForIdle() was implemented in a way that it should block the thread on which it was run until all events will be processed on EDT *and* on native queue. It also takes into account that if at least one event was processed on EDT/native then it should start from the beginning because native events may generate event on EDT, and events on EDT may generate the native events.

So it is unclear why if does not work.

--
Best regards, Sergey.