Mus Event Targeting
Mus Meeting, 2017/02/21
Two Phases of Event Delivery
- Targeting: figure out which client actually gets the events
- Dispatching: sending the events to the right client
Dispatching
- Mus gets the event
- Sends the event to the client
- All done except for the bugs
Targeting
- What is it?
- Determining which client on the screen gets the event
- More complicated...
Clarifying Pictures: Window Tree
Only Direct Dispatching is Secure
Remember: WS must dispatch
But CFs Position Surfaces
The Fundamental Targeting Challenge
- Only WS may dispatch
- Some events are latched and WS already knows the target. e.g.
ET_TOUCH_MOVED
- But not all events are latched: e.g.
ET_TOUCH_PRESSED
- And only the DC knows where surfaces are on the
display::Screen
- But WS and DC are in separate processes
- So, how does WS determine what surface is at a given
display::Screen position?
Answer:have the WS ask the DC which surface is topmost at a given position.
Aside: Web Platform Complications
- Surface targeting works perfectly for transformed rectangular regions
- But correct web platform support requires two extensions
- Transparent occluders
- Solution: extend
cc::CompositorFrame with list of
transparent occluders
- Conceivably also useful for UI (e.g. large touch regions on small window controls)
2nd Complication: Non-rectangular regions
-
- Solution: detect via non-opaque tiles in
cc::CompositorFrame
- And do immediate targeting
How We Build It
Latched Targeting
Unlatched Targeting
Immediate Unlatched Targeting