Mustash Event Targeting

Mustash Meeting, 2017/08/08

Two Phases of Event Delivery

1. Targeting: figure out which client actually gets the events
2. Dispatching: sending the events to the right client

Dispatching

• The host (ws or browser) gets the event
• Sends the event to the client
• Existing implementation is complete except for the bugs
• Only the WS is permitted to do this

Targeting

• What is it?
• Determining which client on the screen gets the event
• More complicated...
• WS makes targeting decisions using AggregatedHitTestRegion information produced by VIZ
• VIZ produces the AggregatedHitTestRegion from HitTestRegion objects that accompany each submission of a CompositorFrame object.
• Sometimes the information contained in a AggregatedHitTestRegion cannot resolve how to target an event. In this case, the WS requests assistance recursively from its clients.

Hit Testing Overview

Prepping the HitTest data

Clients Prep HitTestRegion Objects

• Client code implements viz::HitTestDataProvider
• Such as aura::HitTestDataProviderAura
• List of quads: embedded surfaces D1 and Dn, primary region C and any additional such as tabs
• Fall-back to immediate mode for shapes that cannot be represented with a union of quads

Surface Sync Controls HitTest Aggregation

Aggregator Produces a new Aggregate

Swap Active Aggregate

Viz Host Queries Aggregate

WS Logic: A Serialized Tree

• AggregatedHitTestRegion is a tree
• But in a pointer-less form that can be shared between processes

Immediate Mode

• Some shapes cannot be targeted with quads
• The client marks the HitTestRegion with kHitTestAsk
• So HitTestQuery asks the client for assistance for events in that region: the bounding box of the cloud above

Requesting Client Assistance

Status...

• What I've described is landed or in review
• Blink Paint / CC Impl integration is in planning stages
• Current goal: end to end operation for Aura next week.