Hi Martin, 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!
Thanks, Krishna > On 18-Oct-2018, at 2:15 PM, Martin Balao <mba...@redhat.com> wrote: > > Hi Laurent, > > On Wed, Oct 17, 2018 at 8:13 PM, Laurent Bourgès <bourges.laur...@gmail.com > <mailto:bourges.laur...@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 [1] 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. > > Regards, > Martin.- > > -- > [1] - http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014429.html > <http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014429.html>
