dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Services/WebContent/WebContentCompositorHost.cpp

287 lines
11 KiB
C++
Raw Permalink Normal View History

LibWeb+WebContent: Route compositor through in-process IPC LibWeb still exposed the concrete CompositorThread to Page, Navigable, and EventHandler, so compositor IPC would have leaked the thread implementation into callers. The old thread APIs also bundled page presentation callbacks and main-thread wakeups into the same object, which made it awkward for WebContent to put an actor boundary in between. Introduce CompositorHost and context handles as the caller-facing API, and move shared compositor protocol values out of CompositorThread. Add WebContentCompositor IPC endpoints and route PageHost through a paired in-process transport. The actor owns CompositorThread with explicit main-thread and UI presentation clients, while screenshot completion is serialized on the WebContent event loop using request IDs. The intention for introducing IPC here is to prepare for moving the compositor thread into a separate process.
2026-05-20 13:14:36 -03:00
/*
* Copyright (c) 2026-present, the Ladybird developers.
*
* SPDX-License-Identifier: BSD-2-Clause
*/
LibWeb+LibWebView+WebContent: Delete compositor thread Compositor process is now the only supported compositor topology, so the old in-process compositor thread and its WebContent-local IPC bridge are dead code.
2026-05-24 16:57:32 -03:00
#include <AK/NonnullOwnPtr.h>
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
#include <AK/Optional.h>
#include <LibGfx/CanvasCommandList.h>
LibWeb+WebContent: Route compositor through in-process IPC LibWeb still exposed the concrete CompositorThread to Page, Navigable, and EventHandler, so compositor IPC would have leaked the thread implementation into callers. The old thread APIs also bundled page presentation callbacks and main-thread wakeups into the same object, which made it awkward for WebContent to put an actor boundary in between. Introduce CompositorHost and context handles as the caller-facing API, and move shared compositor protocol values out of CompositorThread. Add WebContentCompositor IPC endpoints and route PageHost through a paired in-process transport. The actor owns CompositorThread with explicit main-thread and UI presentation clients, while screenshot completion is serialized on the WebContent event loop using request IDs. The intention for introducing IPC here is to prepare for moving the compositor thread into a separate process.
2026-05-20 13:14:36 -03:00
#include <LibGfx/PaintingSurface.h>
#include <LibMedia/VideoFrame.h>
LibWeb+LibWebView+WebContent: Delete compositor thread Compositor process is now the only supported compositor topology, so the old in-process compositor thread and its WebContent-local IPC bridge are dead code.
2026-05-24 16:57:32 -03:00
#include <LibWeb/Compositor/CompositorHost.h>
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
#include <LibWeb/HTML/Canvas/RemoteCanvas2DTransport.h>
#include <LibWeb/WebGL/RemoteWebGLTransport.h>
LibWebView+WebContent: Add feature-gated Compositor process backend 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.
2026-05-22 11:17:27 -03:00
#include <WebContent/CompositorConnection.h>
#include <WebContent/ConnectionFromClient.h>
LibWeb+WebContent: Route compositor through in-process IPC LibWeb still exposed the concrete CompositorThread to Page, Navigable, and EventHandler, so compositor IPC would have leaked the thread implementation into callers. The old thread APIs also bundled page presentation callbacks and main-thread wakeups into the same object, which made it awkward for WebContent to put an actor boundary in between. Introduce CompositorHost and context handles as the caller-facing API, and move shared compositor protocol values out of CompositorThread. Add WebContentCompositor IPC endpoints and route PageHost through a paired in-process transport. The actor owns CompositorThread with explicit main-thread and UI presentation clients, while screenshot completion is serialized on the WebContent event loop using request IDs. The intention for introducing IPC here is to prepare for moving the compositor thread into a separate process.
2026-05-20 13:14:36 -03:00
#include <WebContent/WebContentCompositorHost.h>
namespace WebContent {
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
class WebContentRemoteWebGLTransport final : public Web::WebGL::RemoteWebGLTransport {
public:
explicit WebContentRemoteWebGLTransport(NonnullRefPtr<CompositorConnection> connection)
: m_connection(move(connection))
{
}
private:
virtual CreateResult create_context(Web::WebGL::WebGLVersion webgl_version, Gfx::IntSize initial_size, bool depth, bool stencil, bool antialias) override
{
LibWeb+Compositor: Run canvas contexts in the Compositor Canvas rendering is a major remaining path where WebContent directly owns GPU-facing drawing state. Back 2D and WebGL canvas contexts with remote Compositor transports, so WebContent talks to canvas surfaces through IPC while the Compositor owns the rasterization resources. This is a large step toward GPU sandboxing because canvas GPU work now lives behind the Compositor boundary. It also gives OffscreenCanvas the process-independent canvas plumbing that HTMLCanvasElement now uses, making worker-owned canvases possible without another WebContent-local rendering path.
2026-06-15 14:37:51 -03:00
VERIFY(!m_canvas_id.has_value());
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
CreateResult result;
auto canvas_id = m_connection->create_webgl_context(webgl_version, initial_size, depth, stencil, antialias, result.supported_extensions);
if (canvas_id.has_value()) {
result.success = true;
LibWeb+Compositor: Run canvas contexts in the Compositor Canvas rendering is a major remaining path where WebContent directly owns GPU-facing drawing state. Back 2D and WebGL canvas contexts with remote Compositor transports, so WebContent talks to canvas surfaces through IPC while the Compositor owns the rasterization resources. This is a large step toward GPU sandboxing because canvas GPU work now lives behind the Compositor boundary. It also gives OffscreenCanvas the process-independent canvas plumbing that HTMLCanvasElement now uses, making worker-owned canvases possible without another WebContent-local rendering path.
2026-06-15 14:37:51 -03:00
m_canvas_id = *canvas_id;
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
}
return result;
}
LibWeb+Compositor: Run canvas contexts in the Compositor Canvas rendering is a major remaining path where WebContent directly owns GPU-facing drawing state. Back 2D and WebGL canvas contexts with remote Compositor transports, so WebContent talks to canvas surfaces through IPC while the Compositor owns the rasterization resources. This is a large step toward GPU sandboxing because canvas GPU work now lives behind the Compositor boundary. It also gives OffscreenCanvas the process-independent canvas plumbing that HTMLCanvasElement now uses, making worker-owned canvases possible without another WebContent-local rendering path.
2026-06-15 14:37:51 -03:00
virtual Optional<Web::Painting::CanvasId> canvas_id() const override
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
{
LibWeb+Compositor: Run canvas contexts in the Compositor Canvas rendering is a major remaining path where WebContent directly owns GPU-facing drawing state. Back 2D and WebGL canvas contexts with remote Compositor transports, so WebContent talks to canvas surfaces through IPC while the Compositor owns the rasterization resources. This is a large step toward GPU sandboxing because canvas GPU work now lives behind the Compositor boundary. It also gives OffscreenCanvas the process-independent canvas plumbing that HTMLCanvasElement now uses, making worker-owned canvases possible without another WebContent-local rendering path.
2026-06-15 14:37:51 -03:00
return m_canvas_id;
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
}
LibWeb+Compositor: Run canvas contexts in the Compositor Canvas rendering is a major remaining path where WebContent directly owns GPU-facing drawing state. Back 2D and WebGL canvas contexts with remote Compositor transports, so WebContent talks to canvas surfaces through IPC while the Compositor owns the rasterization resources. This is a large step toward GPU sandboxing because canvas GPU work now lives behind the Compositor boundary. It also gives OffscreenCanvas the process-independent canvas plumbing that HTMLCanvasElement now uses, making worker-owned canvases possible without another WebContent-local rendering path.
2026-06-15 14:37:51 -03:00
virtual void destroy_context() override
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
{
LibWeb+Compositor: Run canvas contexts in the Compositor Canvas rendering is a major remaining path where WebContent directly owns GPU-facing drawing state. Back 2D and WebGL canvas contexts with remote Compositor transports, so WebContent talks to canvas surfaces through IPC while the Compositor owns the rasterization resources. This is a large step toward GPU sandboxing because canvas GPU work now lives behind the Compositor boundary. It also gives OffscreenCanvas the process-independent canvas plumbing that HTMLCanvasElement now uses, making worker-owned canvases possible without another WebContent-local rendering path.
2026-06-15 14:37:51 -03:00
if (!m_canvas_id.has_value())
return;
m_connection->destroy_canvas_context(*m_canvas_id);
m_canvas_id.clear();
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
}
LibWeb+Compositor: Run canvas contexts in the Compositor Canvas rendering is a major remaining path where WebContent directly owns GPU-facing drawing state. Back 2D and WebGL canvas contexts with remote Compositor transports, so WebContent talks to canvas surfaces through IPC while the Compositor owns the rasterization resources. This is a large step toward GPU sandboxing because canvas GPU work now lives behind the Compositor boundary. It also gives OffscreenCanvas the process-independent canvas plumbing that HTMLCanvasElement now uses, making worker-owned canvases possible without another WebContent-local rendering path.
2026-06-15 14:37:51 -03:00
virtual void send_commands(ByteBuffer const& commands, Vector<Gfx::DecodedImageFrame> const& bitmaps) override
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
{
LibWeb+Compositor: Run canvas contexts in the Compositor Canvas rendering is a major remaining path where WebContent directly owns GPU-facing drawing state. Back 2D and WebGL canvas contexts with remote Compositor transports, so WebContent talks to canvas surfaces through IPC while the Compositor owns the rasterization resources. This is a large step toward GPU sandboxing because canvas GPU work now lives behind the Compositor boundary. It also gives OffscreenCanvas the process-independent canvas plumbing that HTMLCanvasElement now uses, making worker-owned canvases possible without another WebContent-local rendering path.
2026-06-15 14:37:51 -03:00
if (!m_canvas_id.has_value())
return;
m_connection->send_webgl_commands(*m_canvas_id, commands, bitmaps);
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
}
LibWeb+Compositor: Run canvas contexts in the Compositor Canvas rendering is a major remaining path where WebContent directly owns GPU-facing drawing state. Back 2D and WebGL canvas contexts with remote Compositor transports, so WebContent talks to canvas surfaces through IPC while the Compositor owns the rasterization resources. This is a large step toward GPU sandboxing because canvas GPU work now lives behind the Compositor boundary. It also gives OffscreenCanvas the process-independent canvas plumbing that HTMLCanvasElement now uses, making worker-owned canvases possible without another WebContent-local rendering path.
2026-06-15 14:37:51 -03:00
virtual void present_canvas(bool preserve_drawing_buffer) override
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
{
LibWeb+Compositor: Run canvas contexts in the Compositor Canvas rendering is a major remaining path where WebContent directly owns GPU-facing drawing state. Back 2D and WebGL canvas contexts with remote Compositor transports, so WebContent talks to canvas surfaces through IPC while the Compositor owns the rasterization resources. This is a large step toward GPU sandboxing because canvas GPU work now lives behind the Compositor boundary. It also gives OffscreenCanvas the process-independent canvas plumbing that HTMLCanvasElement now uses, making worker-owned canvases possible without another WebContent-local rendering path.
2026-06-15 14:37:51 -03:00
if (!m_canvas_id.has_value())
return;
m_connection->present_webgl_canvas(*m_canvas_id, preserve_drawing_buffer);
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
}
LibWeb+Compositor: Run canvas contexts in the Compositor Canvas rendering is a major remaining path where WebContent directly owns GPU-facing drawing state. Back 2D and WebGL canvas contexts with remote Compositor transports, so WebContent talks to canvas surfaces through IPC while the Compositor owns the rasterization resources. This is a large step toward GPU sandboxing because canvas GPU work now lives behind the Compositor boundary. It also gives OffscreenCanvas the process-independent canvas plumbing that HTMLCanvasElement now uses, making worker-owned canvases possible without another WebContent-local rendering path.
2026-06-15 14:37:51 -03:00
virtual ByteBuffer sync_call(ByteBuffer request) override
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
{
LibWeb+Compositor: Run canvas contexts in the Compositor Canvas rendering is a major remaining path where WebContent directly owns GPU-facing drawing state. Back 2D and WebGL canvas contexts with remote Compositor transports, so WebContent talks to canvas surfaces through IPC while the Compositor owns the rasterization resources. This is a large step toward GPU sandboxing because canvas GPU work now lives behind the Compositor boundary. It also gives OffscreenCanvas the process-independent canvas plumbing that HTMLCanvasElement now uses, making worker-owned canvases possible without another WebContent-local rendering path.
2026-06-15 14:37:51 -03:00
if (!m_canvas_id.has_value())
return {};
return m_connection->webgl_sync_call(*m_canvas_id, move(request));
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
}
LibWeb+Compositor: Run canvas contexts in the Compositor Canvas rendering is a major remaining path where WebContent directly owns GPU-facing drawing state. Back 2D and WebGL canvas contexts with remote Compositor transports, so WebContent talks to canvas surfaces through IPC while the Compositor owns the rasterization resources. This is a large step toward GPU sandboxing because canvas GPU work now lives behind the Compositor boundary. It also gives OffscreenCanvas the process-independent canvas plumbing that HTMLCanvasElement now uses, making worker-owned canvases possible without another WebContent-local rendering path.
2026-06-15 14:37:51 -03:00
virtual Web::WebGL::ReadPixelsResult read_pixels_robust_angle(Web::WebGL::GLint x, Web::WebGL::GLint y, Web::WebGL::GLsizei width, Web::WebGL::GLsizei height, Web::WebGL::GLenum format, Web::WebGL::GLenum type, Web::WebGL::GLsizei buf_size, Core::AnonymousBuffer pixels) override
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
{
LibWeb+Compositor: Run canvas contexts in the Compositor Canvas rendering is a major remaining path where WebContent directly owns GPU-facing drawing state. Back 2D and WebGL canvas contexts with remote Compositor transports, so WebContent talks to canvas surfaces through IPC while the Compositor owns the rasterization resources. This is a large step toward GPU sandboxing because canvas GPU work now lives behind the Compositor boundary. It also gives OffscreenCanvas the process-independent canvas plumbing that HTMLCanvasElement now uses, making worker-owned canvases possible without another WebContent-local rendering path.
2026-06-15 14:37:51 -03:00
if (!m_canvas_id.has_value())
return {};
return m_connection->read_webgl_pixels(*m_canvas_id, x, y, width, height, format, type, buf_size, pixels);
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
}
LibWeb+Compositor: Run canvas contexts in the Compositor Canvas rendering is a major remaining path where WebContent directly owns GPU-facing drawing state. Back 2D and WebGL canvas contexts with remote Compositor transports, so WebContent talks to canvas surfaces through IPC while the Compositor owns the rasterization resources. This is a large step toward GPU sandboxing because canvas GPU work now lives behind the Compositor boundary. It also gives OffscreenCanvas the process-independent canvas plumbing that HTMLCanvasElement now uses, making worker-owned canvases possible without another WebContent-local rendering path.
2026-06-15 14:37:51 -03:00
virtual void read_buffer_sub_data(Web::WebGL::GLenum target, Web::WebGL::GLintptr offset, Web::WebGL::GLintptr size, Core::AnonymousBuffer data) override
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
{
LibWeb+Compositor: Run canvas contexts in the Compositor Canvas rendering is a major remaining path where WebContent directly owns GPU-facing drawing state. Back 2D and WebGL canvas contexts with remote Compositor transports, so WebContent talks to canvas surfaces through IPC while the Compositor owns the rasterization resources. This is a large step toward GPU sandboxing because canvas GPU work now lives behind the Compositor boundary. It also gives OffscreenCanvas the process-independent canvas plumbing that HTMLCanvasElement now uses, making worker-owned canvases possible without another WebContent-local rendering path.
2026-06-15 14:37:51 -03:00
if (!m_canvas_id.has_value())
return;
m_connection->read_webgl_buffer_sub_data(*m_canvas_id, target, offset, size, data);
}
virtual Gfx::ShareableBitmap read_back_drawing_buffer(Gfx::IntRect const& rect) override
{
if (!m_canvas_id.has_value())
return {};
return m_connection->get_canvas_pixels(*m_canvas_id, rect);
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
}
NonnullRefPtr<CompositorConnection> m_connection;
LibWeb+Compositor: Run canvas contexts in the Compositor Canvas rendering is a major remaining path where WebContent directly owns GPU-facing drawing state. Back 2D and WebGL canvas contexts with remote Compositor transports, so WebContent talks to canvas surfaces through IPC while the Compositor owns the rasterization resources. This is a large step toward GPU sandboxing because canvas GPU work now lives behind the Compositor boundary. It also gives OffscreenCanvas the process-independent canvas plumbing that HTMLCanvasElement now uses, making worker-owned canvases possible without another WebContent-local rendering path.
2026-06-15 14:37:51 -03:00
Optional<Web::Painting::CanvasId> m_canvas_id;
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
};
class WebContentRemoteCanvas2DTransport final : public Web::HTML::RemoteCanvas2DTransport {
public:
explicit WebContentRemoteCanvas2DTransport(NonnullRefPtr<CompositorConnection> connection)
: m_connection(move(connection))
{
}
private:
LibWeb+Compositor: Run canvas contexts in the Compositor Canvas rendering is a major remaining path where WebContent directly owns GPU-facing drawing state. Back 2D and WebGL canvas contexts with remote Compositor transports, so WebContent talks to canvas surfaces through IPC while the Compositor owns the rasterization resources. This is a large step toward GPU sandboxing because canvas GPU work now lives behind the Compositor boundary. It also gives OffscreenCanvas the process-independent canvas plumbing that HTMLCanvasElement now uses, making worker-owned canvases possible without another WebContent-local rendering path.
2026-06-15 14:37:51 -03:00
virtual bool create_context(Gfx::IntSize size, bool alpha) override
{
VERIFY(!m_canvas_id.has_value());
auto canvas_id = m_connection->create_canvas_2d_context(size, alpha);
if (!canvas_id.has_value())
return false;
m_canvas_id = *canvas_id;
return true;
}
virtual Optional<Web::Painting::CanvasId> canvas_id() const override
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
{
LibWeb+Compositor: Run canvas contexts in the Compositor Canvas rendering is a major remaining path where WebContent directly owns GPU-facing drawing state. Back 2D and WebGL canvas contexts with remote Compositor transports, so WebContent talks to canvas surfaces through IPC while the Compositor owns the rasterization resources. This is a large step toward GPU sandboxing because canvas GPU work now lives behind the Compositor boundary. It also gives OffscreenCanvas the process-independent canvas plumbing that HTMLCanvasElement now uses, making worker-owned canvases possible without another WebContent-local rendering path.
2026-06-15 14:37:51 -03:00
return m_canvas_id;
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
}
LibWeb+Compositor: Run canvas contexts in the Compositor Canvas rendering is a major remaining path where WebContent directly owns GPU-facing drawing state. Back 2D and WebGL canvas contexts with remote Compositor transports, so WebContent talks to canvas surfaces through IPC while the Compositor owns the rasterization resources. This is a large step toward GPU sandboxing because canvas GPU work now lives behind the Compositor boundary. It also gives OffscreenCanvas the process-independent canvas plumbing that HTMLCanvasElement now uses, making worker-owned canvases possible without another WebContent-local rendering path.
2026-06-15 14:37:51 -03:00
virtual void destroy_context() override
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
{
LibWeb+Compositor: Run canvas contexts in the Compositor Canvas rendering is a major remaining path where WebContent directly owns GPU-facing drawing state. Back 2D and WebGL canvas contexts with remote Compositor transports, so WebContent talks to canvas surfaces through IPC while the Compositor owns the rasterization resources. This is a large step toward GPU sandboxing because canvas GPU work now lives behind the Compositor boundary. It also gives OffscreenCanvas the process-independent canvas plumbing that HTMLCanvasElement now uses, making worker-owned canvases possible without another WebContent-local rendering path.
2026-06-15 14:37:51 -03:00
if (!m_canvas_id.has_value())
return;
m_connection->destroy_canvas_context(*m_canvas_id);
m_canvas_id.clear();
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
}
LibGfx+LibWeb+Compositor+WebContent: Commit 2D canvas flushes atomically 2D canvas contexts started publishing partial frames after canvas rasterization moved into the Compositor. WebContent still splits large recorded command lists after 64 commands, but every split batch was sent through the same compositor path as the end-of-frame flush. The compositor replayed each batch into the DrawCanvas source surface, so a pending present could sample a canvas after clear and before the rest of the next frame had been drawn. Canvas-heavy pages such as slither.com then flickered between partial and complete frames. Carry an explicit commit bit with 2D canvas command updates. Non-commit batches now update a hidden working canvas in the Compositor, while the display-list-visible surface keeps the last committed canvas contents. The end-of-frame canvas preparation sends the commit boundary, including the empty-commit case needed when the auto-flush consumed all recorded commands before prepare_for_compositing() runs.
2026-06-18 18:12:08 -03:00
virtual void update_commands(Gfx::CanvasCommandList const& commands, bool commit) override
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
{
LibWeb+Compositor: Run canvas contexts in the Compositor Canvas rendering is a major remaining path where WebContent directly owns GPU-facing drawing state. Back 2D and WebGL canvas contexts with remote Compositor transports, so WebContent talks to canvas surfaces through IPC while the Compositor owns the rasterization resources. This is a large step toward GPU sandboxing because canvas GPU work now lives behind the Compositor boundary. It also gives OffscreenCanvas the process-independent canvas plumbing that HTMLCanvasElement now uses, making worker-owned canvases possible without another WebContent-local rendering path.
2026-06-15 14:37:51 -03:00
if (!m_canvas_id.has_value())
return;
LibGfx+LibWeb+Compositor+WebContent: Commit 2D canvas flushes atomically 2D canvas contexts started publishing partial frames after canvas rasterization moved into the Compositor. WebContent still splits large recorded command lists after 64 commands, but every split batch was sent through the same compositor path as the end-of-frame flush. The compositor replayed each batch into the DrawCanvas source surface, so a pending present could sample a canvas after clear and before the rest of the next frame had been drawn. Canvas-heavy pages such as slither.com then flickered between partial and complete frames. Carry an explicit commit bit with 2D canvas command updates. Non-commit batches now update a hidden working canvas in the Compositor, while the display-list-visible surface keeps the last committed canvas contents. The end-of-frame canvas preparation sends the commit boundary, including the empty-commit case needed when the auto-flush consumed all recorded commands before prepare_for_compositing() runs.
2026-06-18 18:12:08 -03:00
m_connection->update_canvas_2d_commands(*m_canvas_id, commands, commit);
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
}
LibWeb+Compositor: Run canvas contexts in the Compositor Canvas rendering is a major remaining path where WebContent directly owns GPU-facing drawing state. Back 2D and WebGL canvas contexts with remote Compositor transports, so WebContent talks to canvas surfaces through IPC while the Compositor owns the rasterization resources. This is a large step toward GPU sandboxing because canvas GPU work now lives behind the Compositor boundary. It also gives OffscreenCanvas the process-independent canvas plumbing that HTMLCanvasElement now uses, making worker-owned canvases possible without another WebContent-local rendering path.
2026-06-15 14:37:51 -03:00
virtual RefPtr<Gfx::Bitmap> read_back_pixels(Gfx::IntRect const& rect) override
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
{
LibWeb+Compositor: Run canvas contexts in the Compositor Canvas rendering is a major remaining path where WebContent directly owns GPU-facing drawing state. Back 2D and WebGL canvas contexts with remote Compositor transports, so WebContent talks to canvas surfaces through IPC while the Compositor owns the rasterization resources. This is a large step toward GPU sandboxing because canvas GPU work now lives behind the Compositor boundary. It also gives OffscreenCanvas the process-independent canvas plumbing that HTMLCanvasElement now uses, making worker-owned canvases possible without another WebContent-local rendering path.
2026-06-15 14:37:51 -03:00
if (!m_canvas_id.has_value())
return nullptr;
auto shareable_bitmap = m_connection->get_canvas_pixels(*m_canvas_id, rect);
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
if (!shareable_bitmap.is_valid())
return nullptr;
return shareable_bitmap.bitmap();
}
NonnullRefPtr<CompositorConnection> m_connection;
LibWeb+Compositor: Run canvas contexts in the Compositor Canvas rendering is a major remaining path where WebContent directly owns GPU-facing drawing state. Back 2D and WebGL canvas contexts with remote Compositor transports, so WebContent talks to canvas surfaces through IPC while the Compositor owns the rasterization resources. This is a large step toward GPU sandboxing because canvas GPU work now lives behind the Compositor boundary. It also gives OffscreenCanvas the process-independent canvas plumbing that HTMLCanvasElement now uses, making worker-owned canvases possible without another WebContent-local rendering path.
2026-06-15 14:37:51 -03:00
Optional<Web::Painting::CanvasId> m_canvas_id;
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
};
WebContent: Rename process compositor host The WebContent compositor host is now always backed by the compositor process, so the private ProcessWebContentCompositorHost name no longer distinguishes it from another implementation. Rename the internal class to WebContentCompositorHost while keeping the existing factory API unchanged.
2026-05-24 17:25:20 -03:00
class WebContentCompositorHost final : public Web::Compositor::CompositorHost {
LibWebView+WebContent: Add feature-gated Compositor process backend 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.
2026-05-22 11:17:27 -03:00
public:
WebContent: Rename process compositor host The WebContent compositor host is now always backed by the compositor process, so the private ProcessWebContentCompositorHost name no longer distinguishes it from another implementation. Rename the internal class to WebContentCompositorHost while keeping the existing factory API unchanged.
2026-05-24 17:25:20 -03:00
explicit WebContentCompositorHost(ConnectionFromClient& client)
LibWebView+WebContent: Add feature-gated Compositor process backend 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.
2026-05-22 11:17:27 -03:00
: m_client(client)
{
}
private:
Meta+LibWeb+Compositor: Add remote canvas transports The display list can now refer to canvas ids, but WebContent still had no channel for creating or updating those canvas resources in the Compositor. Both 2D and WebGL canvases would have had to grow the IPC plumbing in the same commit that changes the rendering contexts. This adds the Compositor-side CanvasHost, WebContent transport objects, and the IPC/CMake pieces needed to allocate, update, read back, and destroy remote canvas contexts. The rendering contexts are not switched over yet, keeping this as plumbing for later commits.
2026-06-15 14:29:43 -03:00
virtual RefPtr<Web::WebGL::RemoteWebGLTransport> create_webgl_transport() override
{
if (auto* connection = compositor_connection())
return adopt_ref(*new WebContentRemoteWebGLTransport(*connection));
return nullptr;
}
virtual RefPtr<Web::HTML::RemoteCanvas2DTransport> create_canvas_2d_transport() override
{
if (auto* connection = compositor_connection())
return adopt_ref(*new WebContentRemoteCanvas2DTransport(*connection));
return nullptr;
}
LibWebView+WebContent: Add feature-gated Compositor process backend 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.
2026-05-22 11:17:27 -03:00
virtual void destroy_context(Web::Compositor::CompositorContextId context_id) override
{
LibWeb+LibWebView+WebContent: Recover after Compositor process crashes The browser previously treated the out-of-process Compositor as fatal. Restart the shared Compositor from the browser process, reconnect process-backed WebContent clients, recreate compositor contexts, restore viewport state, and ask WebContent to repaint and republish canvas and media resources. WebContent now marks its compositor connection lost, returns conservative values for synchronous compositor queries while reconnecting, and drops outgoing updates until the replacement transport arrives. Synchronous input queries through the compositor control connection now use fallible IPC. If the Compositor exits after the open check or before the sync reply arrives, scroll and mouse handling report that the Compositor did not handle the event and let the normal WebContent fallback run. Mouse events queued while the Compositor is unavailable now fall back to direct WebContent dispatch. This keeps input completion in step with the pending-event queue. Recovery is capped at three automatic restarts. If the restart limit is exceeded, if restart, reconnect, or context recreation fails, or if the replacement Compositor exits during active recovery, the browser crashes instead of switching process-backed views to a fallback path.
2026-05-23 22:36:24 -03:00
if (auto* connection = compositor_connection())
connection->destroy_context(context_id);
LibWebView+WebContent: Add feature-gated Compositor process backend 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.
2026-05-22 11:17:27 -03:00
m_client.did_destroy_compositor_context(context_id);
}
LibWeb+Compositor+WebContent: Simplify nested context composition Nested navigables were represented through compositor surface ids owned by the parent context. That forced CompositorState and ContextState to maintain bidirectional attach/detach bookkeeping, publish child snapshots into a surface map, and keep presentation mode variants just to distinguish UI presentation from parent composition. Record the child compositor context id directly in the display list and let the compositor resolve it against the painting parent at playback time. Child contexts now keep their parent context id and latest rendered surface, while parents no longer track child maps or compositor surface ids. UI presentation is represented separately from parent composition, so closing a page only stops client presentation and nested contexts keep using set_parent_context.
2026-06-18 01:10:37 -03:00
virtual void set_parent_context(Web::Compositor::CompositorContextId context_id, Optional<Web::Compositor::CompositorContextId> parent_context_id) override
LibWebView+WebContent: Add feature-gated Compositor process backend 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.
2026-05-22 11:17:27 -03:00
{
LibWeb+LibWebView+WebContent: Recover after Compositor process crashes The browser previously treated the out-of-process Compositor as fatal. Restart the shared Compositor from the browser process, reconnect process-backed WebContent clients, recreate compositor contexts, restore viewport state, and ask WebContent to repaint and republish canvas and media resources. WebContent now marks its compositor connection lost, returns conservative values for synchronous compositor queries while reconnecting, and drops outgoing updates until the replacement transport arrives. Synchronous input queries through the compositor control connection now use fallible IPC. If the Compositor exits after the open check or before the sync reply arrives, scroll and mouse handling report that the Compositor did not handle the event and let the normal WebContent fallback run. Mouse events queued while the Compositor is unavailable now fall back to direct WebContent dispatch. This keeps input completion in step with the pending-event queue. Recovery is capped at three automatic restarts. If the restart limit is exceeded, if restart, reconnect, or context recreation fails, or if the replacement Compositor exits during active recovery, the browser crashes instead of switching process-backed views to a fallback path.
2026-05-23 22:36:24 -03:00
if (auto* connection = compositor_connection())
LibWeb+Compositor+WebContent: Simplify nested context composition Nested navigables were represented through compositor surface ids owned by the parent context. That forced CompositorState and ContextState to maintain bidirectional attach/detach bookkeeping, publish child snapshots into a surface map, and keep presentation mode variants just to distinguish UI presentation from parent composition. Record the child compositor context id directly in the display list and let the compositor resolve it against the painting parent at playback time. Child contexts now keep their parent context id and latest rendered surface, while parents no longer track child maps or compositor surface ids. UI presentation is represented separately from parent composition, so closing a page only stops client presentation and nested contexts keep using set_parent_context.
2026-06-18 01:10:37 -03:00
connection->set_parent_context(context_id, parent_context_id);
}
virtual void stop_presenting_to_client(Web::Compositor::CompositorContextId context_id) override
{
if (auto* connection = compositor_connection())
connection->stop_presenting_to_client(context_id);
LibWebView+WebContent: Add feature-gated Compositor process backend 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.
2026-05-22 11:17:27 -03:00
}
Compositor+LibWeb: Pass AVC trees separately from display lists Display lists owned the accumulated visual context tree through a ref-counted pointer. That tied visual-context state to display-list lifetime and made compositor updates treat the two as one unit, even though AVC trees need to become independently updateable compositor state. Make accumulated visual context trees plain versioned values, have each display list store the compatible tree version, and pass the matching tree alongside display-list updates and replay calls. Replay verifies that the provided tree matches the display list before executing it. This prepares the compositor for receiving AVC tree updates separately from display-list updates: it now accepts the tree as a separate update parameter, stores it next to the display list, and uses that stored tree for replay and async-scroll hit testing. Nested display-list resources carry their own tree snapshots for the same version check.
2026-05-27 12:51:03 -03:00
virtual void update_display_list(Web::Compositor::CompositorContextId context_id, NonnullRefPtr<Web::Painting::DisplayList> display_list, Web::Painting::AccumulatedVisualContextTree visual_context_tree, Web::Painting::DisplayListResourceTransaction&& resource_transaction, Web::Painting::ScrollStateSnapshot&& scroll_state_snapshot) override
LibWebView+WebContent: Add feature-gated Compositor process backend 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.
2026-05-22 11:17:27 -03:00
{
LibWeb+LibWebView+WebContent: Recover after Compositor process crashes The browser previously treated the out-of-process Compositor as fatal. Restart the shared Compositor from the browser process, reconnect process-backed WebContent clients, recreate compositor contexts, restore viewport state, and ask WebContent to repaint and republish canvas and media resources. WebContent now marks its compositor connection lost, returns conservative values for synchronous compositor queries while reconnecting, and drops outgoing updates until the replacement transport arrives. Synchronous input queries through the compositor control connection now use fallible IPC. If the Compositor exits after the open check or before the sync reply arrives, scroll and mouse handling report that the Compositor did not handle the event and let the normal WebContent fallback run. Mouse events queued while the Compositor is unavailable now fall back to direct WebContent dispatch. This keeps input completion in step with the pending-event queue. Recovery is capped at three automatic restarts. If the restart limit is exceeded, if restart, reconnect, or context recreation fails, or if the replacement Compositor exits during active recovery, the browser crashes instead of switching process-backed views to a fallback path.
2026-05-23 22:36:24 -03:00
if (auto* connection = compositor_connection())
Compositor+LibWeb: Pass AVC trees separately from display lists Display lists owned the accumulated visual context tree through a ref-counted pointer. That tied visual-context state to display-list lifetime and made compositor updates treat the two as one unit, even though AVC trees need to become independently updateable compositor state. Make accumulated visual context trees plain versioned values, have each display list store the compatible tree version, and pass the matching tree alongside display-list updates and replay calls. Replay verifies that the provided tree matches the display list before executing it. This prepares the compositor for receiving AVC tree updates separately from display-list updates: it now accepts the tree as a separate update parameter, stores it next to the display list, and uses that stored tree for replay and async-scroll hit testing. Nested display-list resources carry their own tree snapshots for the same version check.
2026-05-27 12:51:03 -03:00
connection->update_display_list(context_id, display_list, visual_context_tree, resource_transaction, scroll_state_snapshot);
LibWebView+WebContent: Add feature-gated Compositor process backend 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.
2026-05-22 11:17:27 -03:00
}
Compositor+LibWeb+WebContent: Add visual context tree update IPC Display list updates already ship their compatible accumulated visual context tree to the compositor, but there was no way to replace only the tree for an existing display list. That kept any visual-context-only change tied to a full display list update. Add an update_visual_context_tree IPC path from WebContent through the Compositor service. ContextState validates that the incoming tree matches the installed display list's compatible tree version and rebuilds wheel hit-test targets when async scrolling state is present.
2026-06-02 15:39:40 -03:00
virtual void update_visual_context_tree(Web::Compositor::CompositorContextId context_id, Web::Painting::AccumulatedVisualContextTree visual_context_tree) override
{
if (auto* connection = compositor_connection())
connection->update_visual_context_tree(context_id, visual_context_tree);
}
LibWebView+WebContent: Add feature-gated Compositor process backend 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.
2026-05-22 11:17:27 -03:00
virtual void update_video_frame(Web::Compositor::CompositorContextId context_id, Web::Painting::VideoFrameResourceId frame_id, NonnullRefPtr<Media::VideoFrame const> frame) override
{
LibWeb+LibWebView+WebContent: Recover after Compositor process crashes The browser previously treated the out-of-process Compositor as fatal. Restart the shared Compositor from the browser process, reconnect process-backed WebContent clients, recreate compositor contexts, restore viewport state, and ask WebContent to repaint and republish canvas and media resources. WebContent now marks its compositor connection lost, returns conservative values for synchronous compositor queries while reconnecting, and drops outgoing updates until the replacement transport arrives. Synchronous input queries through the compositor control connection now use fallible IPC. If the Compositor exits after the open check or before the sync reply arrives, scroll and mouse handling report that the Compositor did not handle the event and let the normal WebContent fallback run. Mouse events queued while the Compositor is unavailable now fall back to direct WebContent dispatch. This keeps input completion in step with the pending-event queue. Recovery is capped at three automatic restarts. If the restart limit is exceeded, if restart, reconnect, or context recreation fails, or if the replacement Compositor exits during active recovery, the browser crashes instead of switching process-backed views to a fallback path.
2026-05-23 22:36:24 -03:00
if (auto* connection = compositor_connection())
connection->update_video_frame(context_id, frame_id, frame);
LibWebView+WebContent: Add feature-gated Compositor process backend 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.
2026-05-22 11:17:27 -03:00
}
virtual void clear_video_frame(Web::Compositor::CompositorContextId context_id, Web::Painting::VideoFrameResourceId frame_id) override
{
LibWeb+LibWebView+WebContent: Recover after Compositor process crashes The browser previously treated the out-of-process Compositor as fatal. Restart the shared Compositor from the browser process, reconnect process-backed WebContent clients, recreate compositor contexts, restore viewport state, and ask WebContent to repaint and republish canvas and media resources. WebContent now marks its compositor connection lost, returns conservative values for synchronous compositor queries while reconnecting, and drops outgoing updates until the replacement transport arrives. Synchronous input queries through the compositor control connection now use fallible IPC. If the Compositor exits after the open check or before the sync reply arrives, scroll and mouse handling report that the Compositor did not handle the event and let the normal WebContent fallback run. Mouse events queued while the Compositor is unavailable now fall back to direct WebContent dispatch. This keeps input completion in step with the pending-event queue. Recovery is capped at three automatic restarts. If the restart limit is exceeded, if restart, reconnect, or context recreation fails, or if the replacement Compositor exits during active recovery, the browser crashes instead of switching process-backed views to a fallback path.
2026-05-23 22:36:24 -03:00
if (auto* connection = compositor_connection())
connection->clear_video_frame(context_id, frame_id);
LibWebView+WebContent: Add feature-gated Compositor process backend 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.
2026-05-22 11:17:27 -03:00
}
virtual void update_scroll_state(Web::Compositor::CompositorContextId context_id, Web::Painting::ScrollStateSnapshot&& scroll_state_snapshot) override
{
LibWeb+LibWebView+WebContent: Recover after Compositor process crashes The browser previously treated the out-of-process Compositor as fatal. Restart the shared Compositor from the browser process, reconnect process-backed WebContent clients, recreate compositor contexts, restore viewport state, and ask WebContent to repaint and republish canvas and media resources. WebContent now marks its compositor connection lost, returns conservative values for synchronous compositor queries while reconnecting, and drops outgoing updates until the replacement transport arrives. Synchronous input queries through the compositor control connection now use fallible IPC. If the Compositor exits after the open check or before the sync reply arrives, scroll and mouse handling report that the Compositor did not handle the event and let the normal WebContent fallback run. Mouse events queued while the Compositor is unavailable now fall back to direct WebContent dispatch. This keeps input completion in step with the pending-event queue. Recovery is capped at three automatic restarts. If the restart limit is exceeded, if restart, reconnect, or context recreation fails, or if the replacement Compositor exits during active recovery, the browser crashes instead of switching process-backed views to a fallback path.
2026-05-23 22:36:24 -03:00
if (auto* connection = compositor_connection())
connection->update_scroll_state(context_id, scroll_state_snapshot);
LibWebView+WebContent: Add feature-gated Compositor process backend 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.
2026-05-22 11:17:27 -03:00
}
virtual void invalidate_wheel_event_listener_state(Web::Compositor::CompositorContextId context_id, u64 generation) override
{
LibWeb+LibWebView+WebContent: Recover after Compositor process crashes The browser previously treated the out-of-process Compositor as fatal. Restart the shared Compositor from the browser process, reconnect process-backed WebContent clients, recreate compositor contexts, restore viewport state, and ask WebContent to repaint and republish canvas and media resources. WebContent now marks its compositor connection lost, returns conservative values for synchronous compositor queries while reconnecting, and drops outgoing updates until the replacement transport arrives. Synchronous input queries through the compositor control connection now use fallible IPC. If the Compositor exits after the open check or before the sync reply arrives, scroll and mouse handling report that the Compositor did not handle the event and let the normal WebContent fallback run. Mouse events queued while the Compositor is unavailable now fall back to direct WebContent dispatch. This keeps input completion in step with the pending-event queue. Recovery is capped at three automatic restarts. If the restart limit is exceeded, if restart, reconnect, or context recreation fails, or if the replacement Compositor exits during active recovery, the browser crashes instead of switching process-backed views to a fallback path.
2026-05-23 22:36:24 -03:00
if (auto* connection = compositor_connection())
connection->invalidate_wheel_event_listener_state(context_id, generation);
LibWebView+WebContent: Add feature-gated Compositor process backend 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.
2026-05-22 11:17:27 -03:00
}
virtual Web::Compositor::AsyncScrollEnqueueResult async_scroll_by(Web::Compositor::CompositorContextId context_id, Web::UniqueNodeID expected_document_id, Gfx::FloatPoint position,
Gfx::FloatPoint delta_in_device_pixels, Gfx::IntRect viewport_rect, Web::Compositor::AsyncScrollOperationTracking operation_tracking) override
{
LibWeb+LibWebView+WebContent: Recover after Compositor process crashes The browser previously treated the out-of-process Compositor as fatal. Restart the shared Compositor from the browser process, reconnect process-backed WebContent clients, recreate compositor contexts, restore viewport state, and ask WebContent to repaint and republish canvas and media resources. WebContent now marks its compositor connection lost, returns conservative values for synchronous compositor queries while reconnecting, and drops outgoing updates until the replacement transport arrives. Synchronous input queries through the compositor control connection now use fallible IPC. If the Compositor exits after the open check or before the sync reply arrives, scroll and mouse handling report that the Compositor did not handle the event and let the normal WebContent fallback run. Mouse events queued while the Compositor is unavailable now fall back to direct WebContent dispatch. This keeps input completion in step with the pending-event queue. Recovery is capped at three automatic restarts. If the restart limit is exceeded, if restart, reconnect, or context recreation fails, or if the replacement Compositor exits during active recovery, the browser crashes instead of switching process-backed views to a fallback path.
2026-05-23 22:36:24 -03:00
if (auto* connection = compositor_connection())
return connection->async_scroll_by(context_id, expected_document_id, position, delta_in_device_pixels, viewport_rect, operation_tracking);
return {};
LibWebView+WebContent: Add feature-gated Compositor process backend 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.
2026-05-22 11:17:27 -03:00
}
virtual bool should_defer_main_thread_present_for_async_scroll(Web::Compositor::CompositorContextId context_id) const override
{
LibWeb+LibWebView+WebContent: Recover after Compositor process crashes The browser previously treated the out-of-process Compositor as fatal. Restart the shared Compositor from the browser process, reconnect process-backed WebContent clients, recreate compositor contexts, restore viewport state, and ask WebContent to repaint and republish canvas and media resources. WebContent now marks its compositor connection lost, returns conservative values for synchronous compositor queries while reconnecting, and drops outgoing updates until the replacement transport arrives. Synchronous input queries through the compositor control connection now use fallible IPC. If the Compositor exits after the open check or before the sync reply arrives, scroll and mouse handling report that the Compositor did not handle the event and let the normal WebContent fallback run. Mouse events queued while the Compositor is unavailable now fall back to direct WebContent dispatch. This keeps input completion in step with the pending-event queue. Recovery is capped at three automatic restarts. If the restart limit is exceeded, if restart, reconnect, or context recreation fails, or if the replacement Compositor exits during active recovery, the browser crashes instead of switching process-backed views to a fallback path.
2026-05-23 22:36:24 -03:00
if (auto* connection = compositor_connection())
return connection->should_defer_main_thread_present_for_async_scroll(context_id);
return false;
LibWebView+WebContent: Add feature-gated Compositor process backend 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.
2026-05-22 11:17:27 -03:00
}
virtual Web::Compositor::PendingAsyncScrollUpdates take_pending_async_scroll_updates(Web::Compositor::CompositorContextId context_id) override
{
LibWeb+LibWebView+WebContent: Recover after Compositor process crashes The browser previously treated the out-of-process Compositor as fatal. Restart the shared Compositor from the browser process, reconnect process-backed WebContent clients, recreate compositor contexts, restore viewport state, and ask WebContent to repaint and republish canvas and media resources. WebContent now marks its compositor connection lost, returns conservative values for synchronous compositor queries while reconnecting, and drops outgoing updates until the replacement transport arrives. Synchronous input queries through the compositor control connection now use fallible IPC. If the Compositor exits after the open check or before the sync reply arrives, scroll and mouse handling report that the Compositor did not handle the event and let the normal WebContent fallback run. Mouse events queued while the Compositor is unavailable now fall back to direct WebContent dispatch. This keeps input completion in step with the pending-event queue. Recovery is capped at three automatic restarts. If the restart limit is exceeded, if restart, reconnect, or context recreation fails, or if the replacement Compositor exits during active recovery, the browser crashes instead of switching process-backed views to a fallback path.
2026-05-23 22:36:24 -03:00
if (auto* connection = compositor_connection())
return connection->take_pending_async_scroll_updates(context_id);
return {};
LibWebView+WebContent: Add feature-gated Compositor process backend 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.
2026-05-22 11:17:27 -03:00
}
Compositor: Drop redundant context state 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.
2026-05-27 14:26:14 -03:00
virtual void viewport_size_updated(Web::Compositor::CompositorContextId context_id, Gfx::IntSize viewport_size, Web::Compositor::WindowResizingInProgress window_resize_in_progress) override
LibWebView+WebContent: Add feature-gated Compositor process backend 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.
2026-05-22 11:17:27 -03:00
{
LibWeb+LibWebView+WebContent: Recover after Compositor process crashes The browser previously treated the out-of-process Compositor as fatal. Restart the shared Compositor from the browser process, reconnect process-backed WebContent clients, recreate compositor contexts, restore viewport state, and ask WebContent to repaint and republish canvas and media resources. WebContent now marks its compositor connection lost, returns conservative values for synchronous compositor queries while reconnecting, and drops outgoing updates until the replacement transport arrives. Synchronous input queries through the compositor control connection now use fallible IPC. If the Compositor exits after the open check or before the sync reply arrives, scroll and mouse handling report that the Compositor did not handle the event and let the normal WebContent fallback run. Mouse events queued while the Compositor is unavailable now fall back to direct WebContent dispatch. This keeps input completion in step with the pending-event queue. Recovery is capped at three automatic restarts. If the restart limit is exceeded, if restart, reconnect, or context recreation fails, or if the replacement Compositor exits during active recovery, the browser crashes instead of switching process-backed views to a fallback path.
2026-05-23 22:36:24 -03:00
if (auto* connection = compositor_connection())
Compositor: Drop redundant context state 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.
2026-05-27 14:26:14 -03:00
connection->viewport_size_updated(context_id, viewport_size, window_resize_in_progress);
LibWebView+WebContent: Add feature-gated Compositor process backend 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.
2026-05-22 11:17:27 -03:00
}
virtual void present_frame(Web::Compositor::CompositorContextId context_id, Gfx::IntRect viewport_rect) override
{
LibWeb+LibWebView+WebContent: Recover after Compositor process crashes The browser previously treated the out-of-process Compositor as fatal. Restart the shared Compositor from the browser process, reconnect process-backed WebContent clients, recreate compositor contexts, restore viewport state, and ask WebContent to repaint and republish canvas and media resources. WebContent now marks its compositor connection lost, returns conservative values for synchronous compositor queries while reconnecting, and drops outgoing updates until the replacement transport arrives. Synchronous input queries through the compositor control connection now use fallible IPC. If the Compositor exits after the open check or before the sync reply arrives, scroll and mouse handling report that the Compositor did not handle the event and let the normal WebContent fallback run. Mouse events queued while the Compositor is unavailable now fall back to direct WebContent dispatch. This keeps input completion in step with the pending-event queue. Recovery is capped at three automatic restarts. If the restart limit is exceeded, if restart, reconnect, or context recreation fails, or if the replacement Compositor exits during active recovery, the browser crashes instead of switching process-backed views to a fallback path.
2026-05-23 22:36:24 -03:00
if (auto* connection = compositor_connection())
connection->present_frame(context_id, viewport_rect);
LibWebView+WebContent: Add feature-gated Compositor process backend 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.
2026-05-22 11:17:27 -03:00
}
virtual void request_screenshot(Web::Compositor::CompositorContextId context_id, NonnullRefPtr<Gfx::PaintingSurface> target_surface, Function<void()>&& callback) override
{
LibWeb+LibWebView+WebContent: Recover after Compositor process crashes The browser previously treated the out-of-process Compositor as fatal. Restart the shared Compositor from the browser process, reconnect process-backed WebContent clients, recreate compositor contexts, restore viewport state, and ask WebContent to repaint and republish canvas and media resources. WebContent now marks its compositor connection lost, returns conservative values for synchronous compositor queries while reconnecting, and drops outgoing updates until the replacement transport arrives. Synchronous input queries through the compositor control connection now use fallible IPC. If the Compositor exits after the open check or before the sync reply arrives, scroll and mouse handling report that the Compositor did not handle the event and let the normal WebContent fallback run. Mouse events queued while the Compositor is unavailable now fall back to direct WebContent dispatch. This keeps input completion in step with the pending-event queue. Recovery is capped at three automatic restarts. If the restart limit is exceeded, if restart, reconnect, or context recreation fails, or if the replacement Compositor exits during active recovery, the browser crashes instead of switching process-backed views to a fallback path.
2026-05-23 22:36:24 -03:00
if (auto* connection = compositor_connection()) {
connection->request_screenshot(context_id, move(target_surface), move(callback));
return;
}
if (callback)
callback();
LibWebView+WebContent: Add feature-gated Compositor process backend 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.
2026-05-22 11:17:27 -03:00
}
LibWeb+LibWebView+WebContent: Recover after Compositor process crashes The browser previously treated the out-of-process Compositor as fatal. Restart the shared Compositor from the browser process, reconnect process-backed WebContent clients, recreate compositor contexts, restore viewport state, and ask WebContent to repaint and republish canvas and media resources. WebContent now marks its compositor connection lost, returns conservative values for synchronous compositor queries while reconnecting, and drops outgoing updates until the replacement transport arrives. Synchronous input queries through the compositor control connection now use fallible IPC. If the Compositor exits after the open check or before the sync reply arrives, scroll and mouse handling report that the Compositor did not handle the event and let the normal WebContent fallback run. Mouse events queued while the Compositor is unavailable now fall back to direct WebContent dispatch. This keeps input completion in step with the pending-event queue. Recovery is capped at three automatic restarts. If the restart limit is exceeded, if restart, reconnect, or context recreation fails, or if the replacement Compositor exits during active recovery, the browser crashes instead of switching process-backed views to a fallback path.
2026-05-23 22:36:24 -03:00
CompositorConnection* compositor_connection() const
LibWebView+WebContent: Add feature-gated Compositor process backend 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.
2026-05-22 11:17:27 -03:00
{
return m_client.compositor_process_connection();
}
ConnectionFromClient& m_client;
};
NonnullOwnPtr<Web::Compositor::CompositorHost> create_web_content_compositor_host(ConnectionFromClient& client)
LibWeb+WebContent: Route compositor through in-process IPC LibWeb still exposed the concrete CompositorThread to Page, Navigable, and EventHandler, so compositor IPC would have leaked the thread implementation into callers. The old thread APIs also bundled page presentation callbacks and main-thread wakeups into the same object, which made it awkward for WebContent to put an actor boundary in between. Introduce CompositorHost and context handles as the caller-facing API, and move shared compositor protocol values out of CompositorThread. Add WebContentCompositor IPC endpoints and route PageHost through a paired in-process transport. The actor owns CompositorThread with explicit main-thread and UI presentation clients, while screenshot completion is serialized on the WebContent event loop using request IDs. The intention for introducing IPC here is to prepare for moving the compositor thread into a separate process.
2026-05-20 13:14:36 -03:00
{
WebContent: Rename process compositor host The WebContent compositor host is now always backed by the compositor process, so the private ProcessWebContentCompositorHost name no longer distinguishes it from another implementation. Rename the internal class to WebContentCompositorHost while keeping the existing factory API unchanged.
2026-05-24 17:25:20 -03:00
return make<WebContentCompositorHost>(client);
LibWeb+WebContent: Route compositor through in-process IPC LibWeb still exposed the concrete CompositorThread to Page, Navigable, and EventHandler, so compositor IPC would have leaked the thread implementation into callers. The old thread APIs also bundled page presentation callbacks and main-thread wakeups into the same object, which made it awkward for WebContent to put an actor boundary in between. Introduce CompositorHost and context handles as the caller-facing API, and move shared compositor protocol values out of CompositorThread. Add WebContentCompositor IPC endpoints and route PageHost through a paired in-process transport. The actor owns CompositorThread with explicit main-thread and UI presentation clients, while screenshot completion is serialized on the WebContent event loop using request IDs. The intention for introducing IPC here is to prepare for moving the compositor thread into a separate process.
2026-05-20 13:14:36 -03:00
}
}
Reference in a new issue Copy permalink