<AWT Dev> OpenJdk11-28-EA JDialog hanging
bourges.laurent at gmail.com
Thu Oct 18 09:05:07 UTC 2018
If the behavior changed in your patch, it sounds more conservative to
>> discard events (as before) if the present bug is still fixed.
>> It could be revisited later in another appropriate bug.
>> Is it a trivial change in your event filter ? I am looking forward trying
>> this alternative sllution.
> I believe that this decision -whether we dispatch, block o completely
> change the approach- has to be taken as part of this bug. We would need to
> further investigate, particularly on the SequencedEvent clients side.
I agree. I think Sergey & Krishna prefer discarding non - SequencedEvent as
before (for compatibility reasons).
Discarding non-SequencedEvent events or holding them for the future is a
> trivial change. In fact, I tried it some days ago before proposing the
> latest version of the patch. What I noticed in your test at  was: events
> were injected at a high rate, the SequencedEvent.list list steadily grew,
> the EDT was very busy dispatching them -"blocked" like- and there was no
> room for dispatching other events keeping the GUI unresponsive -they were
> rejected by the waiting filter-. If I remember correctly, repainting after
> changing the counter was affected by this.
My former test was more a crash test with intensive event submission.
The new test is more 'cool', as it only uses public Window events
(toBack(), toFront() and I am interested to test it with another patch
variant discarding events.
There is no shame that EDT or event processing consuming lots of cpu
cycles, in such intensive tests.
If the bug is fixed, and GUI is still responsive, that's fine to me.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the awt-dev