Do event targeting while dispatching previous events |
||||
Issue descriptionRight now we don't do event targeting if we are actively dispatching a previous event because the result of event targeting might depend on the result of event dispatching, e.g. a mouse press that would create a capture window followed by other mouse presses, following mouse presses should go to the capture window created by the first mouse press so we need to wait after we received the ack for the first event dispatching to start event targeting for subsequent events. But in some other cases we might not want to wait to do event targeting? E.g. if there are two windows right on top of each other and their close buttons align with each other, say window A is on the top and B is at the bottom, now when user click the close​ button of A (event E1), and click again (event E2) while waiting for the targeting+dispatching of E1, both events should target to A instead of closing both A and B. Explore when we should do event targeting while dispatching previous events.
,
May 23 2017
In some cases, we can more aggressively take advantage of asynchrony than target/dispatch/ack always performed in lock step. For example, consider a stream of mouse moves sampled at 240Hz and the screen redrawing at 60Hz. All four mouse moves will use the same targeting data so can be targeted before the (possibly implicit) ack of updated targeting information arriving.
,
May 23 2017
Even mouse moves can have side effects. Say showing a tooltip/bubble.
,
Feb 26 2018
,
Apr 24 2018
Migrating Proj-Mustash-Mus to components Internals>Services>WindowService and Internals>Services>Ash
,
Aug 15
This bug refers to the event dispatching path that has been removed. |
||||
►
Sign in to add a comment |
||||
Comment 1 by sky@chromium.org
, May 19 2017