Hello Anton,
Thanks for the explanation.
The fix looks good to me.
--Semyon
On 2/1/2016 6:29 PM, Anton Litvinov wrote:
Hello Semyon,
Thank you for review of this fix. This issue depends on race
conditions. In fact this issue is reproducible sometimes also, when
the components are initially added to the container, thus removal with
further addition of the components is not the only scenario of this
bug. In the regression test
"ComponentIsNotDrawnAfterRemoveAddTest.java" of the fix this scenario
is checked by the next line.
"94 checkTestableComponents();"
Thank you,
Anton
On 1/28/2016 7:34 PM, Semyon Sadetsky wrote:
Hi,
In the bug description I read that the issue is only reproducible
when the component is removed and then added again. The suggested
root cause does not explain this. Why the issue is not reproducible
for initially added components?
--Semyon
On 1/26/2016 10:48 PM, Anton Litvinov wrote:
Hello,
Could you please review the following fix for the bug.
Bug: https://bugs.openjdk.java.net/browse/JDK-8139581
Webrev: http://cr.openjdk.java.net/~alitvinov/8139581/jdk9/webrev.00
The bug consists in the fact that sometimes X11 "Expose" events
arriving in Toolkit thread during execution of
"XBaseWindow.init(XCreateWindowParams)" method in another thread are
not handled in the method "XBaseWindow.dispatchToWindow(XEvent)",
because "XBaseWindow.initialising" field equals "NOT_INITIALISED"
and "XBaseWindow.checkInitialised()" returns "false". A result of
such not handled "Expose" events is not drawn AWT component, which
is inserted back to AWT container, and whose
"java.awt.Component.paint(Graphics)" method is not called.
The fix removes "InitialiseState.NOT_INITIALISED" from the code and
this lets the mechanism of waiting for "INITIALISED" state work as
designed in the method "XBaseWindow.checkInitialised".
Thank you,
Anton
