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

229 lines
10 KiB
C++
Raw Permalink Normal View History

Compositor+LibWebView+WebContent: Scaffold opt-in Compositor process The compositor is moving into a dedicated helper process. That requires a process to launch, channels for Browser and WebContent to talk to it over, and client proxies on each side. Land all of that as an inert scaffold first, gated behind --enable-compositor-process, so the default rendering path is unchanged and later commits can fill in the protocol, the service-side state, and the runtime switch against a stable target.
2026-05-22 11:02:42 -03:00
/*
* Copyright (c) 2026, the Ladybird developers.
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#include <Compositor/ConnectionFromWebContent.h>
Compositor+WebContent: Initialize WebContent transport peer pid A WebContent display-list update can send compositor resource attachments over the WebContent-to-compositor transport. On Windows, serializing an attachment requires the destination process id, but this secondary transport never exchanged peer pids before the first message. That left TransportSocketWindows with m_peer_pid == -1 and hit the serialize_attachments() verification when WebContent tried to send the first attachment-bearing compositor update. Add InitTransport to this endpoint and run it immediately after WebContent creates the compositor connection, before any other IPC uses the channel.
2026-06-14 19:13:19 -03:00
#include <LibCore/System.h>
Compositor+WebContent+LibWebView: Implement service-side compositor IPC With CompositorState in place, Browser and WebContent need an actual wire protocol to drive it: which calls are sync, who validates that a WebContent is allowed to touch a given context, how compositor loss propagates back to the renderer. This commit fills in the four endpoints around CompositorState and the matching WebContent-side helpers so the future remote host can forward CompositorHost calls directly. The service still has no clients, so default rendering is unchanged.
2026-05-22 09:00:41 -03:00
#include <LibWeb/Page/InputEvent.h>
Compositor+LibWebView+WebContent: Scaffold opt-in Compositor process The compositor is moving into a dedicated helper process. That requires a process to launch, channels for Browser and WebContent to talk to it over, and client proxies on each side. Land all of that as an inert scaffold first, gated behind --enable-compositor-process, so the default rendering path is unchanged and later commits can fill in the protocol, the service-side state, and the runtime switch against a stable target.
2026-05-22 11:02:42 -03:00
namespace Compositor {
Compositor+WebContent+LibWebView: Implement service-side compositor IPC With CompositorState in place, Browser and WebContent need an actual wire protocol to drive it: which calls are sync, who validates that a WebContent is allowed to touch a given context, how compositor loss propagates back to the renderer. This commit fills in the four endpoints around CompositorState and the matching WebContent-side helpers so the future remote host can forward CompositorHost calls directly. The service still has no clients, so default rendering is unchanged.
2026-05-22 09:00:41 -03:00
ConnectionFromWebContent::ConnectionFromWebContent(NonnullOwnPtr<IPC::Transport> transport, NonnullRefPtr<CompositorState> compositor_state, int client_id)
Compositor+LibWebView+WebContent: Scaffold opt-in Compositor process The compositor is moving into a dedicated helper process. That requires a process to launch, channels for Browser and WebContent to talk to it over, and client proxies on each side. Land all of that as an inert scaffold first, gated behind --enable-compositor-process, so the default rendering path is unchanged and later commits can fill in the protocol, the service-side state, and the runtime switch against a stable target.
2026-05-22 11:02:42 -03:00
: IPC::ConnectionFromClient<CompositorWebContentClientEndpoint, CompositorWebContentServerEndpoint>(*this, move(transport), client_id)
Compositor+WebContent+LibWebView: Implement service-side compositor IPC With CompositorState in place, Browser and WebContent need an actual wire protocol to drive it: which calls are sync, who validates that a WebContent is allowed to touch a given context, how compositor loss propagates back to the renderer. This commit fills in the four endpoints around CompositorState and the matching WebContent-side helpers so the future remote host can forward CompositorHost calls directly. The service still has no clients, so default rendering is unchanged.
2026-05-22 09:00:41 -03:00
, m_compositor_state(move(compositor_state))
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
, m_canvas_host(m_compositor_state->skia_backend_context(), m_compositor_state->canvas_surface_registry())
Compositor+LibWebView+WebContent: Scaffold opt-in Compositor process The compositor is moving into a dedicated helper process. That requires a process to launch, channels for Browser and WebContent to talk to it over, and client proxies on each side. Land all of that as an inert scaffold first, gated behind --enable-compositor-process, so the default rendering path is unchanged and later commits can fill in the protocol, the service-side state, and the runtime switch against a stable target.
2026-05-22 11:02:42 -03:00
{
}
void ConnectionFromWebContent::die()
{
Compositor+WebContent+LibWebView: Implement service-side compositor IPC With CompositorState in place, Browser and WebContent need an actual wire protocol to drive it: which calls are sync, who validates that a WebContent is allowed to touch a given context, how compositor loss propagates back to the renderer. This commit fills in the four endpoints around CompositorState and the matching WebContent-side helpers so the future remote host can forward CompositorHost calls directly. The service still has no clients, so default rendering is unchanged.
2026-05-22 09:00:41 -03:00
auto protector = NonnullRefPtr { *this };
m_compositor_state->destroy_contexts_for_web_content_client(*this);
if (m_on_death)
m_on_death(*this);
Compositor+LibWebView+WebContent: Scaffold opt-in Compositor process The compositor is moving into a dedicated helper process. That requires a process to launch, channels for Browser and WebContent to talk to it over, and client proxies on each side. Land all of that as an inert scaffold first, gated behind --enable-compositor-process, so the default rendering path is unchanged and later commits can fill in the protocol, the service-side state, and the runtime switch against a stable target.
2026-05-22 11:02:42 -03:00
}
Compositor+WebContent+LibWebView: Implement service-side compositor IPC With CompositorState in place, Browser and WebContent need an actual wire protocol to drive it: which calls are sync, who validates that a WebContent is allowed to touch a given context, how compositor loss propagates back to the renderer. This commit fills in the four endpoints around CompositorState and the matching WebContent-side helpers so the future remote host can forward CompositorHost calls directly. The service still has no clients, so default rendering is unchanged.
2026-05-22 09:00:41 -03:00
void ConnectionFromWebContent::notify_compositor_lost()
Compositor+LibWebView+WebContent: Scaffold opt-in Compositor process The compositor is moving into a dedicated helper process. That requires a process to launch, channels for Browser and WebContent to talk to it over, and client proxies on each side. Land all of that as an inert scaffold first, gated behind --enable-compositor-process, so the default rendering path is unchanged and later commits can fill in the protocol, the service-side state, and the runtime switch against a stable target.
2026-05-22 11:02:42 -03:00
{
Compositor+WebContent+LibWebView: Implement service-side compositor IPC With CompositorState in place, Browser and WebContent need an actual wire protocol to drive it: which calls are sync, who validates that a WebContent is allowed to touch a given context, how compositor loss propagates back to the renderer. This commit fills in the four endpoints around CompositorState and the matching WebContent-side helpers so the future remote host can forward CompositorHost calls directly. The service still has no clients, so default rendering is unchanged.
2026-05-22 09:00:41 -03:00
async_did_lose_compositor();
}
Compositor+WebContent: Initialize WebContent transport peer pid A WebContent display-list update can send compositor resource attachments over the WebContent-to-compositor transport. On Windows, serializing an attachment requires the destination process id, but this secondary transport never exchanged peer pids before the first message. That left TransportSocketWindows with m_peer_pid == -1 and hit the serialize_attachments() verification when WebContent tried to send the first attachment-bearing compositor update. Add InitTransport to this endpoint and run it immediately after WebContent creates the compositor connection, before any other IPC uses the channel.
2026-06-14 19:13:19 -03:00
Messages::CompositorWebContentServer::InitTransportResponse ConnectionFromWebContent::init_transport([[maybe_unused]] int peer_pid)
{
#ifdef AK_OS_WINDOWS
m_transport->set_peer_pid(peer_pid);
return Core::System::getpid();
#endif
VERIFY_NOT_REACHED();
}
Compositor+WebContent+LibWebView: Implement service-side compositor IPC With CompositorState in place, Browser and WebContent need an actual wire protocol to drive it: which calls are sync, who validates that a WebContent is allowed to touch a given context, how compositor loss propagates back to the renderer. This commit fills in the four endpoints around CompositorState and the matching WebContent-side helpers so the future remote host can forward CompositorHost calls directly. The service still has no clients, so default rendering is unchanged.
2026-05-22 09:00:41 -03:00
void ConnectionFromWebContent::request_rendering_update()
{
async_request_rendering_update();
}
void ConnectionFromWebContent::dispatch_mouse_event_to_web_content(u64 page_id, Web::MouseEvent const& event)
{
async_mouse_event(page_id, event);
}
void ConnectionFromWebContent::verify_context_is_owned_by_this_connection(Web::Compositor::CompositorContextId context_id)
{
switch (m_compositor_state->check_context_owner(context_id, *this)) {
case CompositorState::ContextOwnerCheckResult::OwnedByClient:
return;
case CompositorState::ContextOwnerCheckResult::ContextUnavailable:
VERIFY_NOT_REACHED();
case CompositorState::ContextOwnerCheckResult::ConflictingOwner:
did_misbehave("WebContent tried to use a compositor context owned by another connection");
VERIFY_NOT_REACHED();
}
VERIFY_NOT_REACHED();
}
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
void ConnectionFromWebContent::set_parent_context(Web::Compositor::CompositorContextId context_id, Optional<Web::Compositor::CompositorContextId> parent_context_id)
Compositor+WebContent+LibWebView: Implement service-side compositor IPC With CompositorState in place, Browser and WebContent need an actual wire protocol to drive it: which calls are sync, who validates that a WebContent is allowed to touch a given context, how compositor loss propagates back to the renderer. This commit fills in the four endpoints around CompositorState and the matching WebContent-side helpers so the future remote host can forward CompositorHost calls directly. The service still has no clients, so default rendering is unchanged.
2026-05-22 09:00:41 -03:00
{
verify_context_is_owned_by_this_connection(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
m_compositor_state->set_parent_context(context_id, parent_context_id);
}
void ConnectionFromWebContent::stop_presenting_to_client(Web::Compositor::CompositorContextId context_id)
{
verify_context_is_owned_by_this_connection(context_id);
m_compositor_state->stop_presenting_to_client(context_id);
Compositor+WebContent+LibWebView: Implement service-side compositor IPC With CompositorState in place, Browser and WebContent need an actual wire protocol to drive it: which calls are sync, who validates that a WebContent is allowed to touch a given context, how compositor loss propagates back to the renderer. This commit fills in the four endpoints around CompositorState and the matching WebContent-side helpers so the future remote host can forward CompositorHost calls directly. The service still has no clients, so default rendering is unchanged.
2026-05-22 09:00:41 -03:00
}
void ConnectionFromWebContent::destroy_context(Web::Compositor::CompositorContextId context_id)
{
verify_context_is_owned_by_this_connection(context_id);
m_compositor_state->destroy_context(context_id);
}
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
void ConnectionFromWebContent::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)
Compositor+WebContent+LibWebView: Implement service-side compositor IPC With CompositorState in place, Browser and WebContent need an actual wire protocol to drive it: which calls are sync, who validates that a WebContent is allowed to touch a given context, how compositor loss propagates back to the renderer. This commit fills in the four endpoints around CompositorState and the matching WebContent-side helpers so the future remote host can forward CompositorHost calls directly. The service still has no clients, so default rendering is unchanged.
2026-05-22 09:00:41 -03:00
{
verify_context_is_owned_by_this_connection(context_id);
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
m_compositor_state->update_display_list(context_id, move(display_list), move(visual_context_tree), move(resource_transaction), move(scroll_state_snapshot));
Compositor+WebContent+LibWebView: Implement service-side compositor IPC With CompositorState in place, Browser and WebContent need an actual wire protocol to drive it: which calls are sync, who validates that a WebContent is allowed to touch a given context, how compositor loss propagates back to the renderer. This commit fills in the four endpoints around CompositorState and the matching WebContent-side helpers so the future remote host can forward CompositorHost calls directly. The service still has no clients, so default rendering is unchanged.
2026-05-22 09:00:41 -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
void ConnectionFromWebContent::update_visual_context_tree(Web::Compositor::CompositorContextId context_id, Web::Painting::AccumulatedVisualContextTree visual_context_tree)
{
verify_context_is_owned_by_this_connection(context_id);
m_compositor_state->update_visual_context_tree(context_id, move(visual_context_tree));
}
Compositor+WebContent+LibWebView: Implement service-side compositor IPC With CompositorState in place, Browser and WebContent need an actual wire protocol to drive it: which calls are sync, who validates that a WebContent is allowed to touch a given context, how compositor loss propagates back to the renderer. This commit fills in the four endpoints around CompositorState and the matching WebContent-side helpers so the future remote host can forward CompositorHost calls directly. The service still has no clients, so default rendering is unchanged.
2026-05-22 09:00:41 -03:00
void ConnectionFromWebContent::update_scroll_state(Web::Compositor::CompositorContextId context_id, Web::Painting::ScrollStateSnapshot scroll_state_snapshot)
{
verify_context_is_owned_by_this_connection(context_id);
m_compositor_state->update_scroll_state(context_id, move(scroll_state_snapshot));
}
void ConnectionFromWebContent::update_video_frame(Web::Compositor::CompositorContextId context_id, Web::Painting::VideoFrameResourceId frame_id, NonnullRefPtr<Media::VideoFrame const> frame)
{
verify_context_is_owned_by_this_connection(context_id);
m_compositor_state->update_video_frame(context_id, frame_id, move(frame));
}
void ConnectionFromWebContent::clear_video_frame(Web::Compositor::CompositorContextId context_id, Web::Painting::VideoFrameResourceId frame_id)
{
verify_context_is_owned_by_this_connection(context_id);
m_compositor_state->clear_video_frame(context_id, frame_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
Messages::CompositorWebContentServer::CreateCanvas2dContextResponse ConnectionFromWebContent::create_canvas_2d_context(Gfx::IntSize size, bool alpha)
{
auto canvas_id = m_canvas_host.create_2d_context(size, alpha);
if (!canvas_id.has_value())
return { false, Web::Painting::CanvasId { 0 } };
return { true, *canvas_id };
}
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
void ConnectionFromWebContent::update_canvas_2d_commands(Web::Painting::CanvasId canvas_id, Gfx::CanvasCommandList commands, bool 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
{
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_canvas_host.execute_canvas_2d_commands(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
}
void ConnectionFromWebContent::destroy_canvas_context(Web::Painting::CanvasId canvas_id)
{
m_canvas_host.destroy_context(canvas_id);
}
Messages::CompositorWebContentServer::GetCanvasPixelsResponse ConnectionFromWebContent::get_canvas_pixels(Web::Painting::CanvasId canvas_id, Gfx::IntRect rect)
{
return m_canvas_host.read_back_pixels(canvas_id, rect);
}
Messages::CompositorWebContentServer::CreateWebglContextResponse ConnectionFromWebContent::create_webgl_context(Web::WebGL::WebGLVersion webgl_version, Gfx::IntSize size, bool depth, bool stencil, bool antialias)
{
auto result = m_canvas_host.create_webgl_context(webgl_version, size, depth, stencil, antialias);
return { result.success, result.canvas_id, move(result.supported_extensions) };
}
void ConnectionFromWebContent::webgl_commands(Web::Painting::CanvasId canvas_id, ByteBuffer commands, Vector<Gfx::DecodedImageFrame> bitmaps)
{
m_canvas_host.execute_webgl_commands(canvas_id, commands, bitmaps);
}
void ConnectionFromWebContent::webgl_present_canvas(Web::Painting::CanvasId canvas_id, bool preserve_drawing_buffer)
{
m_canvas_host.present_webgl_canvas(canvas_id, preserve_drawing_buffer);
}
Messages::CompositorWebContentServer::WebglSyncCallResponse ConnectionFromWebContent::webgl_sync_call(Web::Painting::CanvasId canvas_id, ByteBuffer request)
{
return MUST(m_canvas_host.execute_webgl_sync_call(canvas_id, move(request)));
}
Messages::CompositorWebContentServer::WebglReadPixelsResponse ConnectionFromWebContent::webgl_read_pixels(Web::Painting::CanvasId canvas_id, i32 x, i32 y, i32 width, i32 height, u32 format, u32 type, i32 buf_size, Core::AnonymousBuffer pixels)
{
if (buf_size < 0 || (buf_size > 0 && (!pixels.is_valid() || pixels.size() < static_cast<size_t>(buf_size)))) {
did_misbehave("WebContent sent an invalid WebGL readPixels buffer");
return { 0, 0, 0 };
}
auto result = m_canvas_host.webgl_read_pixels_robust_angle(canvas_id, x, y, width, height, format, type, buf_size, move(pixels));
return { result.length, result.columns, result.rows };
}
void ConnectionFromWebContent::webgl_read_buffer_sub_data(Web::Painting::CanvasId canvas_id, u32 target, i64 offset, i64 size, Core::AnonymousBuffer data)
{
if (size < 0 || (size > 0 && (!data.is_valid() || data.size() < static_cast<size_t>(size)))) {
did_misbehave("WebContent sent an invalid WebGL buffer readback target");
return;
}
m_canvas_host.webgl_read_buffer_sub_data(canvas_id, target, offset, size, move(data));
}
Compositor+WebContent+LibWebView: Implement service-side compositor IPC With CompositorState in place, Browser and WebContent need an actual wire protocol to drive it: which calls are sync, who validates that a WebContent is allowed to touch a given context, how compositor loss propagates back to the renderer. This commit fills in the four endpoints around CompositorState and the matching WebContent-side helpers so the future remote host can forward CompositorHost calls directly. The service still has no clients, so default rendering is unchanged.
2026-05-22 09:00:41 -03:00
void ConnectionFromWebContent::invalidate_wheel_event_listener_state(Web::Compositor::CompositorContextId context_id, u64 generation)
{
verify_context_is_owned_by_this_connection(context_id);
m_compositor_state->invalidate_wheel_event_listener_state(context_id, generation);
}
Messages::CompositorWebContentServer::AsyncScrollByResponse ConnectionFromWebContent::async_scroll_by(Web::Compositor::CompositorContextId context_id, Web::UniqueNodeID document_id, Gfx::FloatPoint position, Gfx::FloatPoint delta, Gfx::IntRect viewport_rect, Web::Compositor::AsyncScrollOperationTracking operation_tracking)
{
verify_context_is_owned_by_this_connection(context_id);
auto result = m_compositor_state->async_scroll_by(context_id, document_id, position, delta, viewport_rect, operation_tracking);
if (result.accepted)
async_request_rendering_update();
return result;
}
Messages::CompositorWebContentServer::ShouldDeferMainThreadPresentForAsyncScrollResponse ConnectionFromWebContent::should_defer_main_thread_present_for_async_scroll(Web::Compositor::CompositorContextId context_id)
{
verify_context_is_owned_by_this_connection(context_id);
return m_compositor_state->should_defer_main_thread_present_for_async_scroll(context_id);
}
Messages::CompositorWebContentServer::TakePendingAsyncScrollUpdatesResponse ConnectionFromWebContent::take_pending_async_scroll_updates(Web::Compositor::CompositorContextId context_id)
{
verify_context_is_owned_by_this_connection(context_id);
return m_compositor_state->take_pending_async_scroll_updates(context_id);
}
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
void ConnectionFromWebContent::viewport_size_updated(Web::Compositor::CompositorContextId context_id, Gfx::IntSize viewport_size, Web::Compositor::WindowResizingInProgress window_resize_in_progress)
Compositor+WebContent+LibWebView: Implement service-side compositor IPC With CompositorState in place, Browser and WebContent need an actual wire protocol to drive it: which calls are sync, who validates that a WebContent is allowed to touch a given context, how compositor loss propagates back to the renderer. This commit fills in the four endpoints around CompositorState and the matching WebContent-side helpers so the future remote host can forward CompositorHost calls directly. The service still has no clients, so default rendering is unchanged.
2026-05-22 09:00:41 -03:00
{
verify_context_is_owned_by_this_connection(context_id);
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
m_compositor_state->viewport_size_updated(context_id, viewport_size, window_resize_in_progress);
Compositor+WebContent+LibWebView: Implement service-side compositor IPC With CompositorState in place, Browser and WebContent need an actual wire protocol to drive it: which calls are sync, who validates that a WebContent is allowed to touch a given context, how compositor loss propagates back to the renderer. This commit fills in the four endpoints around CompositorState and the matching WebContent-side helpers so the future remote host can forward CompositorHost calls directly. The service still has no clients, so default rendering is unchanged.
2026-05-22 09:00:41 -03:00
}
void ConnectionFromWebContent::present_frame(Web::Compositor::CompositorContextId context_id, Gfx::IntRect viewport_rect)
{
verify_context_is_owned_by_this_connection(context_id);
m_compositor_state->present_frame(context_id, viewport_rect);
}
void ConnectionFromWebContent::request_screenshot(Web::Compositor::CompositorContextId context_id, Web::Compositor::ScreenshotRequestId request_id, Gfx::ShareableBitmap target_bitmap)
{
verify_context_is_owned_by_this_connection(context_id);
if (m_compositor_state->request_screenshot(context_id, target_bitmap))
async_did_complete_screenshot(request_id);
else
async_did_fail_screenshot(request_id);
Compositor+LibWebView+WebContent: Scaffold opt-in Compositor process The compositor is moving into a dedicated helper process. That requires a process to launch, channels for Browser and WebContent to talk to it over, and client proxies on each side. Land all of that as an inert scaffold first, gated behind --enable-compositor-process, so the default rendering path is unchanged and later commits can fill in the protocol, the service-side state, and the runtime switch against a stable target.
2026-05-22 11:02:42 -03:00
}
}
Reference in a new issue Copy permalink