Chromium Code Reviews Chromium Code Reviews
Issue
13844021:
Move compositor thread input handling logic into content (Closed)
DescriptionThe moves the compositor thread's input event cracking logic in to content/ from Blink. This significantly decreases the amount of plumbing involved with setting up and tearing down the input filtering and makes it easier to extend without having to go through API rolls.
The startup sequence is as follows, all in the render process:
1.) [main thread] Compositor initialized in content::RenderWidgetCompositor::Create(). During initialization, cc::LayerTreeHost grabs a base::WeakPtr<cc::InputHandler> bounds to the compositor thread. The cc::InputHandler interface is implemented by cc::LayerTreeHostImpl.
2.) [main thread] RenderViewImpl::didActivateCompositor() grabs a WeakPtr to itself and a WeakPtr<cc::InputHandler> from the RenderWidgetCompositor and calls InputHandlerManager::AddInputHandler()
2.) [main thread] InputHandlerManager grabs a WeakPtr<> to its MessageLoopProxy posts a task to itself on the compositor thread to AddInputHandlerOnCompositorThread()
3.) [compositor thread] InputHandlerManager::AddInputHandlerOnCompositorThread() checks if the WeakPtr<cc::InputHandler> is still valid. If the WeakPtr has been invalidated or there's already an entry for this routing_id, it bails. Otherwise InputHandlerManager adds the new routing_id to the filter (which takes a lock on the [ipc thread]) and constructs a new InputHandlerWrapper and adds it to its input_handlers_ map
4.) [compositor thread] InputHandlerWrapper constructs a new InputHandlerClientImpl
5.) [compositor thread] InputHandlerProxy binds itself as the client for the cc::InputHandler
After this completes successfully, the cc::LayerTreeHostImpl has a weak (raw) pointer to the cc::InputHandlerClient, which is the content::InputHandlerProxy, and the InputHandlerProxy has a weak (raw) ptr to the cc::InputHandler, which is the cc::LayerTreeHostImpl. The flow for incoming IPCs is thus:
1.) [ipc thread] IPC message arrives and is dispatched at all IPC filters.
2.) [ipc thread] InputEventFilter::OnMessageReceived checks if the message is an InputMsg_ type. If so, it takes a lock on routes_ and checks if the IPC is intended for a routing_id with filtering. If so, it posts the message to the InputHandlerManager (via ForwardToHandler). If any of these checks fail, the filter rejects the message (returns false) and the IPC goes down the normal handling path which routes it to the main thread.
3.) [compositor thread] InputHandlerManager::HandleInputEvent() looks for an entry in its input_handlers_ map matching the message's routing_id. If there is one, it calls InputHandlerProxy::HandleInputEvent(). If there isn't, it sends the input event to the main thread.
4.) [compositor thread] InputHandlerProxy::HandleInputEvent() examines the fields on the input event and determines what set of logical scroll/pinch/whatnots should occur as a result of the event. To do this, it communicates with the compositor via the cc::InputHandler. After it has determined the disposition of the event, it returns a status to its embedder via the content::InputHandlerProxyClient interface (which is the content::InputHandlerWrapper).
5.) [compositor thread] content::InputHandlerWrapper forwards the event disposition back to the InputEventFilter, which can forward the message to the main thread or send an ACK as appropriate.
Shutdown:
1.) [compositor thread] ~cc::LayerTreeHostImpl() calls WillShutdown() its input_handler_client_, which is a content::InputHandlerProxy
2.) [compositor thread] content::InputHandlerProxy::WillShutdown() calls client_->WillShutdown()
3.) [compositor thread] content::InputHandlerWrapper::WillShutdown() calls input_handler_manager_->RemoveInputHandler() for its routing_id
4.) [compositor thread] content::InputHandlerManager::RemoveInputHandler() calls filters_->RemoveRoute(), which takes a lock on the InputEventFilter's routing table and removes the id, then erases the matching input_handlers_ entry which derefs the InputHandlerWrapper
After step 4 no more messages will be posted from the ipc thread to the compositor thread for the given routing id, but of course any number of tasks may already be posted. When these tasks run InputHandlerManager::HandleInputEvent() will find no matching entries in the input_handlers_ map and will send the messages back to the main thread.
BUG=236096
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=201016
Patch Set 1 #Patch Set 2 : #Patch Set 3 : wip #Patch Set 4 : it\'s alive\! #Patch Set 5 : #
Total comments: 30
Patch Set 6 : addresses most feedback #Patch Set 7 : fix shutdown #Patch Set 8 : fix comments around dcheck #Patch Set 9 : 55% more compilation #Patch Set 10 : fix win component build #
Total comments: 14
Patch Set 11 : fix up ownership and comments #Patch Set 12 : patch in blink changes to WebCompositorInputHandlerImpl* #
Total comments: 8
Patch Set 13 : address feedback #
Total comments: 2
Patch Set 14 : moar dcheck #Patch Set 15 : rebased #Patch Set 16 : fix browser_tests #Patch Set 17 : rebased #Messages
Total messages: 28 (0 generated)
|
