dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Libraries/LibWeb/Painting/AccumulatedVisualContext.cpp

209 lines
8.8 KiB
C++
Raw Normal View History

LibWeb: Introduce AccumulatedVisualContext Introduce AccumulatedVisualContext, a tree structure that tracks the cumulative visual state (scroll offsets, clip regions, transforms, perspective) for each paintable box. Motivation: Before this change, visual state was fragmented across multiple mechanisms: - ClipFrame: Tracked clip rectangles, each storing its own enclosing_scroll_frame_id to handle scroll offset adjustments - scroll_frame_id: Passed separately to each display list command - PushStackingContext: Stored transform matrices directly in the command - Every display list command implemented translate_by() (45 methods total) to allow scroll offset adjustment during playback This fragmentation led to: - Complex, error-prone coordinate transformation logic scattered throughout the codebase - Commands being mutated during playback to apply scroll offsets - Duplicate logic between painting and hit testing for coordinate transformations Solution: AccumulatedVisualContext builds a tree where each node represents a single visual operation: - ScrollData: A scroll frame with its ID - ClipData: A clip rectangle with optional border radii - TransformData: A 4x4 transform matrix with its origin - PerspectiveData: A perspective projection matrix Each PaintableBox stores a reference to its accumulated context node. The tree structure naturally captures the parent-child relationships, so traversing from any node to the root gives the complete chain of visual transformations. Benefits this enables (in subsequent commits): - Display list commands become immutable - no more translate_by() - Single RefPtr<AccumulatedVisualContext> replaces separate scroll_frame_id and ClipFrame on commands - LCA-based tree traversal during playback for efficient save/restore - transform_point_for_hit_test() provides coordinate transformation for hit testing using the same structure
2026-01-13 16:30:32 -03:00
/*
* Copyright (c) 2026, Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
LibWeb: Use local coordinates for overflow clip hit testing
2026-01-21 08:12:31 -03:00
* Copyright (c) 2026, Jelle Raaijmakers <jelle@ladybird.org>
LibWeb: Introduce AccumulatedVisualContext Introduce AccumulatedVisualContext, a tree structure that tracks the cumulative visual state (scroll offsets, clip regions, transforms, perspective) for each paintable box. Motivation: Before this change, visual state was fragmented across multiple mechanisms: - ClipFrame: Tracked clip rectangles, each storing its own enclosing_scroll_frame_id to handle scroll offset adjustments - scroll_frame_id: Passed separately to each display list command - PushStackingContext: Stored transform matrices directly in the command - Every display list command implemented translate_by() (45 methods total) to allow scroll offset adjustment during playback This fragmentation led to: - Complex, error-prone coordinate transformation logic scattered throughout the codebase - Commands being mutated during playback to apply scroll offsets - Duplicate logic between painting and hit testing for coordinate transformations Solution: AccumulatedVisualContext builds a tree where each node represents a single visual operation: - ScrollData: A scroll frame with its ID - ClipData: A clip rectangle with optional border radii - TransformData: A 4x4 transform matrix with its origin - PerspectiveData: A perspective projection matrix Each PaintableBox stores a reference to its accumulated context node. The tree structure naturally captures the parent-child relationships, so traversing from any node to the root gives the complete chain of visual transformations. Benefits this enables (in subsequent commits): - Display list commands become immutable - no more translate_by() - Single RefPtr<AccumulatedVisualContext> replaces separate scroll_frame_id and ClipFrame on commands - LCA-based tree traversal during playback for efficient save/restore - transform_point_for_hit_test() provides coordinate transformation for hit testing using the same structure
2026-01-13 16:30:32 -03:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
LibWeb: Add AccumulatedVisualContext debugging infrastructure
2026-01-13 16:40:48 -03:00
#include <AK/StringBuilder.h>
LibWeb: Introduce AccumulatedVisualContext Introduce AccumulatedVisualContext, a tree structure that tracks the cumulative visual state (scroll offsets, clip regions, transforms, perspective) for each paintable box. Motivation: Before this change, visual state was fragmented across multiple mechanisms: - ClipFrame: Tracked clip rectangles, each storing its own enclosing_scroll_frame_id to handle scroll offset adjustments - scroll_frame_id: Passed separately to each display list command - PushStackingContext: Stored transform matrices directly in the command - Every display list command implemented translate_by() (45 methods total) to allow scroll offset adjustment during playback This fragmentation led to: - Complex, error-prone coordinate transformation logic scattered throughout the codebase - Commands being mutated during playback to apply scroll offsets - Duplicate logic between painting and hit testing for coordinate transformations Solution: AccumulatedVisualContext builds a tree where each node represents a single visual operation: - ScrollData: A scroll frame with its ID - ClipData: A clip rectangle with optional border radii - TransformData: A 4x4 transform matrix with its origin - PerspectiveData: A perspective projection matrix Each PaintableBox stores a reference to its accumulated context node. The tree structure naturally captures the parent-child relationships, so traversing from any node to the root gives the complete chain of visual transformations. Benefits this enables (in subsequent commits): - Display list commands become immutable - no more translate_by() - Single RefPtr<AccumulatedVisualContext> replaces separate scroll_frame_id and ClipFrame on commands - LCA-based tree traversal during playback for efficient save/restore - transform_point_for_hit_test() provides coordinate transformation for hit testing using the same structure
2026-01-13 16:30:32 -03:00
#include <LibGfx/Matrix4x4.h>
#include <LibWeb/Painting/AccumulatedVisualContext.h>
namespace Web::Painting {
NonnullRefPtr<AccumulatedVisualContext> AccumulatedVisualContext::create(size_t id, VisualContextData data, RefPtr<AccumulatedVisualContext const> parent)
{
return adopt_ref(*new AccumulatedVisualContext(id, move(data), move(parent)));
}
LibWeb: Account for border-radius in hit testing This change adds border-radius awareness to hit testing in two places: 1. ClipData::contains() now uses BorderRadiiData::contains() to properly check if a point is inside a rounded clip rect. This handles overflow clips from ancestor elements that have border-radius. 2. PaintableBox::hit_test() now directly checks the element's own border-radius before reporting a hit.
2026-01-19 03:19:23 -03:00
bool ClipData::contains(CSSPixelPoint point) const
{
return corner_radii.contains(point, rect);
}
LibWeb: Introduce AccumulatedVisualContext Introduce AccumulatedVisualContext, a tree structure that tracks the cumulative visual state (scroll offsets, clip regions, transforms, perspective) for each paintable box. Motivation: Before this change, visual state was fragmented across multiple mechanisms: - ClipFrame: Tracked clip rectangles, each storing its own enclosing_scroll_frame_id to handle scroll offset adjustments - scroll_frame_id: Passed separately to each display list command - PushStackingContext: Stored transform matrices directly in the command - Every display list command implemented translate_by() (45 methods total) to allow scroll offset adjustment during playback This fragmentation led to: - Complex, error-prone coordinate transformation logic scattered throughout the codebase - Commands being mutated during playback to apply scroll offsets - Duplicate logic between painting and hit testing for coordinate transformations Solution: AccumulatedVisualContext builds a tree where each node represents a single visual operation: - ScrollData: A scroll frame with its ID - ClipData: A clip rectangle with optional border radii - TransformData: A 4x4 transform matrix with its origin - PerspectiveData: A perspective projection matrix Each PaintableBox stores a reference to its accumulated context node. The tree structure naturally captures the parent-child relationships, so traversing from any node to the root gives the complete chain of visual transformations. Benefits this enables (in subsequent commits): - Display list commands become immutable - no more translate_by() - Single RefPtr<AccumulatedVisualContext> replaces separate scroll_frame_id and ClipFrame on commands - LCA-based tree traversal during playback for efficient save/restore - transform_point_for_hit_test() provides coordinate transformation for hit testing using the same structure
2026-01-13 16:30:32 -03:00
Optional<CSSPixelPoint> AccumulatedVisualContext::transform_point_for_hit_test(CSSPixelPoint screen_point, ScrollStateSnapshot const& scroll_state) const
{
Vector<AccumulatedVisualContext const*> chain;
for (auto const* node = this; node; node = node->parent().ptr())
chain.append(node);
auto point = screen_point;
for (size_t i = chain.size(); i > 0; --i) {
auto const* node = chain[i - 1];
auto result = node->data().visit(
[&](PerspectiveData const& perspective) -> Optional<CSSPixelPoint> {
auto affine = Gfx::extract_2d_affine_transform(perspective.matrix);
auto inverse = affine.inverse();
if (!inverse.has_value())
return {};
point = inverse->map(point.to_type<float>()).to_type<CSSPixels>();
return point;
},
[&](ScrollData const& scroll) -> Optional<CSSPixelPoint> {
auto offset = scroll_state.own_offset_for_frame_with_id(scroll.scroll_frame_id);
point.translate_by(-offset);
return point;
},
[&](TransformData const& transform) -> Optional<CSSPixelPoint> {
auto affine = Gfx::extract_2d_affine_transform(transform.matrix);
auto inverse = affine.inverse();
if (!inverse.has_value())
return {};
auto offset_point = point - transform.origin;
auto transformed = inverse->map(offset_point.to_type<float>()).to_type<CSSPixels>();
point = transformed + transform.origin;
return point;
},
[&](ClipData const& clip) -> Optional<CSSPixelPoint> {
LibWeb: Use local coordinates for overflow clip hit testing
2026-01-21 08:12:31 -03:00
// NOTE: The clip rect is stored in absolute (layout) coordinates. After inverse-transforming, `point`
// is also in layout coordinates, so we compare them directly without mapping back to screen space.
LibWeb: Account for border-radius in hit testing This change adds border-radius awareness to hit testing in two places: 1. ClipData::contains() now uses BorderRadiiData::contains() to properly check if a point is inside a rounded clip rect. This handles overflow clips from ancestor elements that have border-radius. 2. PaintableBox::hit_test() now directly checks the element's own border-radius before reporting a hit.
2026-01-19 03:19:23 -03:00
if (!clip.contains(point))
LibWeb: Introduce AccumulatedVisualContext Introduce AccumulatedVisualContext, a tree structure that tracks the cumulative visual state (scroll offsets, clip regions, transforms, perspective) for each paintable box. Motivation: Before this change, visual state was fragmented across multiple mechanisms: - ClipFrame: Tracked clip rectangles, each storing its own enclosing_scroll_frame_id to handle scroll offset adjustments - scroll_frame_id: Passed separately to each display list command - PushStackingContext: Stored transform matrices directly in the command - Every display list command implemented translate_by() (45 methods total) to allow scroll offset adjustment during playback This fragmentation led to: - Complex, error-prone coordinate transformation logic scattered throughout the codebase - Commands being mutated during playback to apply scroll offsets - Duplicate logic between painting and hit testing for coordinate transformations Solution: AccumulatedVisualContext builds a tree where each node represents a single visual operation: - ScrollData: A scroll frame with its ID - ClipData: A clip rectangle with optional border radii - TransformData: A 4x4 transform matrix with its origin - PerspectiveData: A perspective projection matrix Each PaintableBox stores a reference to its accumulated context node. The tree structure naturally captures the parent-child relationships, so traversing from any node to the root gives the complete chain of visual transformations. Benefits this enables (in subsequent commits): - Display list commands become immutable - no more translate_by() - Single RefPtr<AccumulatedVisualContext> replaces separate scroll_frame_id and ClipFrame on commands - LCA-based tree traversal during playback for efficient save/restore - transform_point_for_hit_test() provides coordinate transformation for hit testing using the same structure
2026-01-13 16:30:32 -03:00
return {};
return point;
LibWeb: Integrate clip-path into AccumulatedVisualContext Previously, clip-path was applied only during painting in StackingContext::paint(), which meant hit testing did not respect clip-path boundaries. Clicks outside the visible clipped region but inside the element's bounding box would incorrectly register as hits. By moving clip-path into AccumulatedVisualContext, it becomes part of the same system that handles transforms, clips, and scroll offsets for both painting and hit testing, ensuring consistent behavior.
2026-01-15 23:56:34 -03:00
},
[&](ClipPathData const& clip_path) -> Optional<CSSPixelPoint> {
LibWeb: Use local coordinates for overflow clip hit testing
2026-01-21 08:12:31 -03:00
// NOTE: The clip path is stored in absolute (layout) coordinates. After inverse-transforming, `point`
// is also in layout coordinates, so we compare them directly without mapping back to screen space.
if (!clip_path.bounding_rect.contains(point))
LibWeb: Integrate clip-path into AccumulatedVisualContext Previously, clip-path was applied only during painting in StackingContext::paint(), which meant hit testing did not respect clip-path boundaries. Clicks outside the visible clipped region but inside the element's bounding box would incorrectly register as hits. By moving clip-path into AccumulatedVisualContext, it becomes part of the same system that handles transforms, clips, and scroll offsets for both painting and hit testing, ensuring consistent behavior.
2026-01-15 23:56:34 -03:00
return {};
LibWeb: Use local coordinates for overflow clip hit testing
2026-01-21 08:12:31 -03:00
if (!clip_path.path.contains(point.to_type<float>(), clip_path.fill_rule))
LibWeb: Integrate clip-path into AccumulatedVisualContext Previously, clip-path was applied only during painting in StackingContext::paint(), which meant hit testing did not respect clip-path boundaries. Clicks outside the visible clipped region but inside the element's bounding box would incorrectly register as hits. By moving clip-path into AccumulatedVisualContext, it becomes part of the same system that handles transforms, clips, and scroll offsets for both painting and hit testing, ensuring consistent behavior.
2026-01-15 23:56:34 -03:00
return {};
return point;
LibWeb: Move effects application into AccumulatedVisualContext Effects (opacity, blend mode, filters) must be applied in the parent's coordinate space, before the element's transform. Previously this was handled by manually switching to the parent's visual context when applying effects at paint time. By adding EffectsData to AccumulatedVisualContext and positioning it before TransformData in the chain, effects are now naturally applied in the correct order during display list replay, eliminating the special case in StackingContext::paint(). For SVG filters that can generate content from empty elements (feFlood, feImage, feTurbulence), a transparent FillRect command is emitted to trigger the filter through the same AVC pipeline.
2026-01-21 07:08:32 -03:00
},
[&](EffectsData const&) -> Optional<CSSPixelPoint> {
// Effects don't affect coordinate transforms
return point;
LibWeb: Introduce AccumulatedVisualContext Introduce AccumulatedVisualContext, a tree structure that tracks the cumulative visual state (scroll offsets, clip regions, transforms, perspective) for each paintable box. Motivation: Before this change, visual state was fragmented across multiple mechanisms: - ClipFrame: Tracked clip rectangles, each storing its own enclosing_scroll_frame_id to handle scroll offset adjustments - scroll_frame_id: Passed separately to each display list command - PushStackingContext: Stored transform matrices directly in the command - Every display list command implemented translate_by() (45 methods total) to allow scroll offset adjustment during playback This fragmentation led to: - Complex, error-prone coordinate transformation logic scattered throughout the codebase - Commands being mutated during playback to apply scroll offsets - Duplicate logic between painting and hit testing for coordinate transformations Solution: AccumulatedVisualContext builds a tree where each node represents a single visual operation: - ScrollData: A scroll frame with its ID - ClipData: A clip rectangle with optional border radii - TransformData: A 4x4 transform matrix with its origin - PerspectiveData: A perspective projection matrix Each PaintableBox stores a reference to its accumulated context node. The tree structure naturally captures the parent-child relationships, so traversing from any node to the root gives the complete chain of visual transformations. Benefits this enables (in subsequent commits): - Display list commands become immutable - no more translate_by() - Single RefPtr<AccumulatedVisualContext> replaces separate scroll_frame_id and ClipFrame on commands - LCA-based tree traversal during playback for efficient save/restore - transform_point_for_hit_test() provides coordinate transformation for hit testing using the same structure
2026-01-13 16:30:32 -03:00
});
if (!result.has_value())
return {};
}
return point;
}
LibWeb: Fix mouse event offset computation with nested CSS transforms compute_mouse_event_offset() only inverted the target element's own CSS transform, ignoring ancestor transforms. This caused incorrect offsetX/ offsetY values when elements were nested inside transformed parents. Use AccumulatedVisualContext::inverse_transform_point() to invert the full ancestor transform chain instead.
2026-01-31 11:34:23 -03:00
CSSPixelPoint AccumulatedVisualContext::inverse_transform_point(CSSPixelPoint screen_point) const
{
Vector<AccumulatedVisualContext const*> chain;
for (auto const* node = this; node; node = node->parent().ptr())
chain.append(node);
auto point = screen_point;
for (size_t i = chain.size(); i > 0; --i) {
auto const* node = chain[i - 1];
node->data().visit(
[&](PerspectiveData const& perspective) {
auto affine = Gfx::extract_2d_affine_transform(perspective.matrix);
auto inverse = affine.inverse();
if (inverse.has_value())
point = inverse->map(point.to_type<float>()).to_type<CSSPixels>();
},
[&](TransformData const& transform) {
auto affine = Gfx::extract_2d_affine_transform(transform.matrix);
auto inverse = affine.inverse();
if (inverse.has_value()) {
auto offset_point = point - transform.origin;
auto transformed = inverse->map(offset_point.to_type<float>()).to_type<CSSPixels>();
point = transformed + transform.origin;
}
},
[&](auto const&) {});
}
return point;
}
LibWeb: Use AccumulatedVisualContext in Element::get_client_rects() The previous implementation had a bug: it composed all ancestor transforms but applied them around only the innermost element's transform origin. The correct behavior is to apply each transform around its own origin. AccumulatedVisualContext already tracks all visual transformations (transforms, scroll offsets, perspective) correctly for hit testing. This change adds a new transform_rect_to_viewport() method that performs the forward transformation (element coordinates to viewport coordinates), which is the inverse direction of transform_point_for_hit_test(). This fixes getBoundingClientRect() returning incorrect coordinates for elements inside transformed ancestors with non-default transform-origins.
2026-01-19 02:23:05 -03:00
CSSPixelRect AccumulatedVisualContext::transform_rect_to_viewport(CSSPixelRect const& source_rect, ScrollStateSnapshot const& scroll_state) const
{
Vector<AccumulatedVisualContext const*> chain;
for (auto const* node = this; node; node = node->parent().ptr())
chain.append(node);
auto rect = source_rect.to_type<float>();
for (auto const* node : chain) {
node->data().visit(
[&](TransformData const& transform) {
auto affine = Gfx::extract_2d_affine_transform(transform.matrix);
auto origin = transform.origin.to_type<float>();
rect.translate_by(-origin);
rect = affine.map(rect);
rect.translate_by(origin);
},
[&](PerspectiveData const& perspective) {
auto affine = Gfx::extract_2d_affine_transform(perspective.matrix);
rect = affine.map(rect);
},
[&](ScrollData const& scroll) {
auto offset = scroll_state.own_offset_for_frame_with_id(scroll.scroll_frame_id);
rect.translate_by(offset.to_type<float>());
},
[&](ClipData const&) { /* clips don't affect rect coordinates */ },
LibWeb: Move effects application into AccumulatedVisualContext Effects (opacity, blend mode, filters) must be applied in the parent's coordinate space, before the element's transform. Previously this was handled by manually switching to the parent's visual context when applying effects at paint time. By adding EffectsData to AccumulatedVisualContext and positioning it before TransformData in the chain, effects are now naturally applied in the correct order during display list replay, eliminating the special case in StackingContext::paint(). For SVG filters that can generate content from empty elements (feFlood, feImage, feTurbulence), a transparent FillRect command is emitted to trigger the filter through the same AVC pipeline.
2026-01-21 07:08:32 -03:00
[&](ClipPathData const&) { /* clip paths don't affect rect coordinates */ },
[&](EffectsData const&) { /* effects don't affect rect coordinates */ });
LibWeb: Use AccumulatedVisualContext in Element::get_client_rects() The previous implementation had a bug: it composed all ancestor transforms but applied them around only the innermost element's transform origin. The correct behavior is to apply each transform around its own origin. AccumulatedVisualContext already tracks all visual transformations (transforms, scroll offsets, perspective) correctly for hit testing. This change adds a new transform_rect_to_viewport() method that performs the forward transformation (element coordinates to viewport coordinates), which is the inverse direction of transform_point_for_hit_test(). This fixes getBoundingClientRect() returning incorrect coordinates for elements inside transformed ancestors with non-default transform-origins.
2026-01-19 02:23:05 -03:00
}
return rect.to_type<CSSPixels>();
}
LibWeb: Add AccumulatedVisualContext debugging infrastructure
2026-01-13 16:40:48 -03:00
void AccumulatedVisualContext::dump(StringBuilder& builder) const
{
m_data.visit(
[&](PerspectiveData const&) {
builder.append("perspective"sv);
},
[&](ScrollData const& scroll) {
builder.appendff("scroll_frame_id={}", scroll.scroll_frame_id);
if (scroll.is_sticky)
builder.append(" (sticky)"sv);
},
[&](TransformData const& transform) {
auto const& matrix = transform.matrix.elements();
auto const& origin = transform.origin;
builder.appendff("transform=[{},{},{},{},{},{}] origin=({},{})", matrix[0][0], matrix[0][1], matrix[1][0], matrix[1][1], matrix[0][3], matrix[1][3], origin.x().to_float(), origin.y().to_float());
},
[&](ClipData const& clip) {
auto const& rect = clip.rect;
builder.appendff("clip=[{},{} {}x{}]", rect.x().to_float(), rect.y().to_float(), rect.width().to_float(), rect.height().to_float());
if (clip.corner_radii.has_any_radius()) {
auto const& corner_radii = clip.corner_radii;
builder.appendff(" radii=({},{},{},{})", corner_radii.top_left.horizontal_radius, corner_radii.top_right.horizontal_radius, corner_radii.bottom_right.horizontal_radius, corner_radii.bottom_left.horizontal_radius);
}
LibWeb: Integrate clip-path into AccumulatedVisualContext Previously, clip-path was applied only during painting in StackingContext::paint(), which meant hit testing did not respect clip-path boundaries. Clicks outside the visible clipped region but inside the element's bounding box would incorrectly register as hits. By moving clip-path into AccumulatedVisualContext, it becomes part of the same system that handles transforms, clips, and scroll offsets for both painting and hit testing, ensuring consistent behavior.
2026-01-15 23:56:34 -03:00
},
[&](ClipPathData const& clip_path) {
auto const& rect = clip_path.bounding_rect;
LibWeb: Include path string in AccumulatedVisualContext::dump() This adds the actual SVG path data to the ClipPathData dump output, making it easier to debug clip-path issues.
2026-01-18 00:09:56 -03:00
builder.appendff("clip_path=[bounds: {},{} {}x{}, path: {}]", rect.x().to_float(), rect.y().to_float(), rect.width().to_float(), rect.height().to_float(), clip_path.path.to_svg_string());
LibWeb: Move effects application into AccumulatedVisualContext Effects (opacity, blend mode, filters) must be applied in the parent's coordinate space, before the element's transform. Previously this was handled by manually switching to the parent's visual context when applying effects at paint time. By adding EffectsData to AccumulatedVisualContext and positioning it before TransformData in the chain, effects are now naturally applied in the correct order during display list replay, eliminating the special case in StackingContext::paint(). For SVG filters that can generate content from empty elements (feFlood, feImage, feTurbulence), a transparent FillRect command is emitted to trigger the filter through the same AVC pipeline.
2026-01-21 07:08:32 -03:00
},
[&](EffectsData const& effects) {
builder.append("effects=["sv);
bool has_content = false;
if (effects.opacity < 1.0f) {
builder.appendff("opacity={}", effects.opacity);
has_content = true;
}
if (effects.blend_mode != Gfx::CompositingAndBlendingOperator::Normal) {
if (has_content)
builder.append(' ');
builder.appendff("blend_mode={}", static_cast<int>(effects.blend_mode));
has_content = true;
}
if (effects.filter.has_filters()) {
if (has_content)
builder.append(' ');
effects.filter.dump(builder);
has_content = true;
}
if (effects.isolate) {
if (has_content)
builder.append(' ');
builder.append("isolate"sv);
}
builder.append("]"sv);
LibWeb: Add AccumulatedVisualContext debugging infrastructure
2026-01-13 16:40:48 -03:00
});
}
LibWeb: Introduce AccumulatedVisualContext Introduce AccumulatedVisualContext, a tree structure that tracks the cumulative visual state (scroll offsets, clip regions, transforms, perspective) for each paintable box. Motivation: Before this change, visual state was fragmented across multiple mechanisms: - ClipFrame: Tracked clip rectangles, each storing its own enclosing_scroll_frame_id to handle scroll offset adjustments - scroll_frame_id: Passed separately to each display list command - PushStackingContext: Stored transform matrices directly in the command - Every display list command implemented translate_by() (45 methods total) to allow scroll offset adjustment during playback This fragmentation led to: - Complex, error-prone coordinate transformation logic scattered throughout the codebase - Commands being mutated during playback to apply scroll offsets - Duplicate logic between painting and hit testing for coordinate transformations Solution: AccumulatedVisualContext builds a tree where each node represents a single visual operation: - ScrollData: A scroll frame with its ID - ClipData: A clip rectangle with optional border radii - TransformData: A 4x4 transform matrix with its origin - PerspectiveData: A perspective projection matrix Each PaintableBox stores a reference to its accumulated context node. The tree structure naturally captures the parent-child relationships, so traversing from any node to the root gives the complete chain of visual transformations. Benefits this enables (in subsequent commits): - Display list commands become immutable - no more translate_by() - Single RefPtr<AccumulatedVisualContext> replaces separate scroll_frame_id and ClipFrame on commands - LCA-based tree traversal during playback for efficient save/restore - transform_point_for_hit_test() provides coordinate transformation for hit testing using the same structure
2026-01-13 16:30:32 -03:00
}
Reference in a new issue Copy permalink