Apply pinch zoom deltas to the compositor's visual viewport transform
so the currently presented display list can respond without waiting for
the WebContent main thread. Keep the normal WebContent pinch event path
so the real VisualViewport state and DOM-visible events catch up after.
Only take the compositor path when async scrolling is enabled and there
are no blocking wheel listeners, since pinch zoom dispatches a synthetic
wheel event that script may cancel. Coalesce queued pinch events in
WebContent so main-thread catch-up can adopt multiple gesture deltas
together.
Use the compositor visual viewport transform for wheel hit testing and
consume wheel deltas as visual viewport pan while zoomed. Scale the
handoff to layout viewport scrolling by the inverse visual viewport
scale, so touchpad momentum does not jump when the visual viewport hits
an edge.
Keep notifying connected WebContent clients that the compositor is
gone, but terminate the Compositor process without running exit-time
destructors after the controlling client disconnects.
Page-presenting compositor contexts still carried a separate tagged ID
namespace and Browser-side page/context maps even though page IDs are
now allocated globally by the UI process. That made context
registration keep two ways to describe the same relationship and
forced compositor IPC to pass an extra presentation bit.
Use each page ID directly as its page-presenting compositor context ID
and allocate non-page compositor contexts from the same Browser-owned
counter. The registration path now sends only the optional page ID, and
Compositor infers client presentation from that page ID.
Compositor presentation happened immediately whenever a frame or async
scroll requested it, so compositor-local updates could run faster than
thedisplay cadence and compete with bitmap ack back-pressure.
Introduce VSyncScheduler as the compositor scheduling interface and add
a TimerVSyncScheduler implementation that uses a single-shot timer at
the context refresh rate on every platform. CompositorState now keeps a
scheduler per display metadata bucket, marks contexts with pending
frames, and drains matching pending contexts from that scheduler while
preserving existing screenshot behavior and async-present ack flow.
The browser process forwards the maximum frame rate to WebContent, but
the compositor process had no copy of that display timing metadata or
the display identity needed by compositor-local vsync.
Add one compositor control IPC message carrying the optional display ID
and refresh rate together, and store both values on each compositor
context.
CompositorState treats presence in m_contexts as the lifetime state
for a compositor context. create_context() creates the entry and
destroy_context() removes it, so ContextState::is_registered duplicated
the map membership invariant.
The top-level-traversable bit was also duplicate information. The
only compositor use was backing-store padding while a window resize is
in progress, and page-presenting contexts are already identified by
PagePresentationRegistration::Yes. Normalize resize-in-progress to No
for non-page-presenting contexts, then remove the flag from
CompositorState, the backing-store API, and the compositor IPC boundary.
Browser UI input can race with compositor context teardown during tab
close. The control connection may ask the compositor to handle, scroll,
or forward a mouse event after WebContent has already destroyed the
context. Treating that as an invariant crashes the compositor even
though the event is stale.
Make the UI-facing mouse handling and async scroll entry points return
false when the context is gone. Mouse forwarding now reports whether it
actually dispatched the event, letting LibWebView fall back to direct
WebContent IPC and preserve the normal input-event acknowledgement flow.
We are moving toward an architecture where the browser owns a single
process that holds the GPU context, so Skia resources can be shared
across every renderer and WebContent processes can be sandboxed away
from direct GPU access. A dedicated Compositor helper process is the
first step. The earlier commits laid the foundation; this one turns the
helper on as a selectable backend, gated behind
--enable-compositor-process so the existing in-process path stays the
shipping default.
Default topology -- one compositor per WebContent, in-process:
+---------+
| Browser |
+---------+
/ | \
v v v
+---+ +---+ +---+ each WebContent runs its own
|WC | |WC | |WC | CompositorThread on a dedicated
|+C+| |+C+| |+C+| thread, with its own GPU context.
+---+ +---+ +---+
Opt-in topology -- one single-threaded Compositor, shared by all WCs:
+---------+ control +-------------------+
| Browser |<----------->| Compositor |
+---------+ | (single thread, |
/ | \ | single GPU ctx, |
v v v data | shared by all |
[WC] [WC] [WC] ---------->| connected WCs) |
+-------------------+
Three IPC channels carry the work in the opt-in topology. The
existing Browser<->WebContent channel gains context allocation.
A new Browser<->Compositor channel carries context lifetime,
viewport, UI input, and presentation acks plus backing-store and
frame upcalls. A new WebContent<->Compositor channel carries
display lists, scroll state, video, compositor surfaces, async
scrolling, presentation, and screenshots, with upcalls for
delegated input and compositor loss.
With CompositorState in place, Browser and WebContent need an actual
wire protocol to drive it: which calls are sync, who validates that a
WebContent is allowed to touch a given context, how compositor loss
propagates back to the renderer. This commit fills in the four endpoints
around CompositorState and the matching WebContent-side helpers so the
future remote host can forward CompositorHost calls directly. The
service still has no clients, so default rendering is unchanged.
The compositor is moving into a dedicated helper process. That requires
a process to launch, channels for Browser and WebContent to talk to it
over, and client proxies on each side. Land all of that as an inert
scaffold first, gated behind --enable-compositor-process, so the default
rendering path is unchanged and later commits can fill in the protocol,
the service-side state, and the runtime switch against a stable target.
