<AWT Dev> OpenJdk11-28-EA JDialog hanging
krishna.addepalli at oracle.com
Thu Oct 18 09:32:15 UTC 2018
As far as my experience goes(which is less), the usage of SequencedEvents is relatively rare, and rarer even to generate a high volume of SequencedEvents.
So, I would be inclined to pursue the path of blocking the dispatch till the SequencedEvents are processed.
Probably Sergey/Phil are more qualified to comment on this, but this is my 2 cents!
> On 18-Oct-2018, at 2:15 PM, Martin Balao <mbalao at redhat.com> wrote:
> Hi Laurent,
> On Wed, Oct 17, 2018 at 8:13 PM, Laurent Bourgès <bourges.laurent at gmail.com <mailto:bourges.laurent at gmail.com>> wrote:
> 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.
> 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.
>  - http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014429.html <http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014429.html>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the awt-dev