Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-19 15:43:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/Painting/StackingContext.cpp

496 lines
23 KiB
C++
Raw Normal View History

LibWeb: Respect CSS z-index property while painting To support z-ordering when painting, the layout tree now has a parallel sparse tree of stacking contexts. The rules for which layout boxes establish a stacking context are a bit complex, but the intent is to encapsulate the decision making into establishes_stacking_context(). When we paint, we start from the ICB (LayoutDocument) who always has a StackingContext and then paint the tree of StackingContexts where each node has its children sorted by z-index. This is pretty crude, but gets the basic job done. Note that this does not yet support hit testing; hit testing is still done using a naive treewalk from the root.
2020-06-15 17:29:35 +02:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 13:19:50 +02:00
* Copyright (c) 2020-2022, Andreas Kling <andreas@ladybird.org>
LibWeb: Store calculated transformation matrix on the StackingContext This is mainly so we can easily read that matrix later, but also has the benefit of only calculating the matrix once, instead of every time we paint. :^)
2022-07-19 15:18:20 +01:00
* Copyright (c) 2022, Sam Atkins <atkinssj@serenityos.org>
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
* Copyright (c) 2024, Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
LibWeb: Respect CSS z-index property while painting To support z-ordering when painting, the layout tree now has a parallel sparse tree of stacking contexts. The rules for which layout boxes establish a stacking context are a bit complex, but the intent is to encapsulate the decision making into establishes_stacking_context(). When we paint, we start from the ICB (LayoutDocument) who always has a StackingContext and then paint the tree of StackingContexts where each node has its children sorted by z-index. This is pretty crude, but gets the basic job done. Note that this does not yet support hit testing; hit testing is still done using a naive treewalk from the root.
2020-06-15 17:29:35 +02:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 01:24:48 -07:00
* SPDX-License-Identifier: BSD-2-Clause
LibWeb: Respect CSS z-index property while painting To support z-ordering when painting, the layout tree now has a parallel sparse tree of stacking contexts. The rules for which layout boxes establish a stacking context are a bit complex, but the intent is to encapsulate the decision making into establishes_stacking_context(). When we paint, we start from the ICB (LayoutDocument) who always has a StackingContext and then paint the tree of StackingContexts where each node has its children sorted by z-index. This is pretty crude, but gets the basic job done. Note that this does not yet support hit testing; hit testing is still done using a naive treewalk from the root.
2020-06-15 17:29:35 +02:00
*/
#include <AK/QuickSort.h>
LibWeb: Implement CSS transforms on stacking contexts Since there is currently no easy way to handle rotations and skews with LibGfx this only implements translation and scaling by first constructing a general 4x4 transformation matrix like outlined in the css-transforms-1 specification. This is then downgraded to a Gfx::AffineTransform in order to transform the destination rectangle used with draw_scaled_bitmap() While rotation would be nice this already looks pretty good :^)
2022-03-18 01:29:20 +01:00
#include <LibGfx/AffineTransform.h>
#include <LibGfx/Matrix4x4.h>
#include <LibGfx/Rect.h>
LibWeb: Split TransformationStyleValue out of StyleValue.{h,cpp}
2023-03-24 17:59:33 +00:00
#include <LibWeb/CSS/StyleValues/TransformationStyleValue.h>
LibWeb: Rename LayoutNode classes and move them into Layout namespace Bring the names of various boxes closer to spec language. This should hopefully make things easier to understand and hack on. :^) Some notable changes: - LayoutNode -> Layout::Node - LayoutBox -> Layout::Box - LayoutBlock -> Layout::BlockBox - LayoutReplaced -> Layout::ReplacedBox - LayoutDocument -> Layout::InitialContainingBlockBox - LayoutText -> Layout::TextNode - LayoutInline -> Layout::InlineNode Note that this is not strictly a "box tree" as we also hang inline/text nodes in the same tree, and they don't generate boxes. (Instead, they contribute line box fragments to their containing block!)
2020-11-22 15:53:01 +01:00
#include <LibWeb/Layout/Box.h>
LibWeb: Paint inline-level and replaced elements on top of floats This matches CSS 2.1 appendix E, and fixes an instance of red face border on ACID2. :^)
2022-02-14 16:39:45 +01:00
#include <LibWeb/Layout/ReplacedBox.h>
LibWeb: Rename Layout::InitialContainingBlock to Layout::Viewport The name "initial containing block" was wrong for this, as it doesn't correspond to the HTML element, and that's specifically what it's supposed to do! :^)
2023-02-25 11:04:29 +01:00
#include <LibWeb/Layout/Viewport.h>
LibWeb: Reduce number of recompiled files for display list headers This reduces the number of `.cpp` files that need to be recompiled when one of the below header files changes as follows: Painting/Command.h: 1030 -> 61 Painting/DisplayList.h: 1030 -> 60 Painting/DisplayListRecorder.h: 557 -> 59
2025-02-02 15:55:26 +01:00
#include <LibWeb/Painting/DisplayListRecorder.h>
LibWeb: Move PaintingBox to its own .cpp and .h files
2022-03-10 23:13:37 +01:00
#include <LibWeb/Painting/PaintableBox.h>
LibWeb: Don't allow SVG boxes to create a stacking context Prior to this change, SVGs were following the CSS painting order, which means SVG boxes could have established stacking context and be sorted by z-index. There is a section in the spec that defines what kind of SVG boxes should create a stacking context https://www.w3.org/TR/SVG2/render.html#EstablishingStackingContex Although this spec is marked as a draft and rendering order described in this spec does not match what other engines do. This spec issue comment has a good summary of what other engines actually do regarding painting order https://github.com/w3c/svgwg/issues/264#issuecomment-246432360 "as long as you're relying solely on the default z-index (which SVG1 does, by definition), nothing ever changes order when you apply opacity/filter/etc". This change aligns our implementation with other engines by forbidding SVGs to create a formatting context and painting them in order they are defined in tree tree.
2024-10-09 02:57:57 +02:00
#include <LibWeb/Painting/SVGSVGPaintable.h>
LibWeb: Fix broken #include after moving files around
2020-06-18 22:01:05 +02:00
#include <LibWeb/Painting/StackingContext.h>
LibWeb: Resolve and paint simple SVG masks This allows applying SVG <mask>s to elements. It is only implemented for the simplest (and default) case: - mask-type = luminance - maskContentUnits = maskContentUnits - maskUnits = objectBoundingBox - Default masking area It should be possible to extend to cover more cases. Though the layout for maskContentUnits = objectBoundingBox will be tricky to figure out.
2023-09-10 14:10:55 +01:00
#include <LibWeb/SVG/SVGMaskElement.h>
LibWeb: Respect CSS z-index property while painting To support z-ordering when painting, the layout tree now has a parallel sparse tree of stacking contexts. The rules for which layout boxes establish a stacking context are a bit complex, but the intent is to encapsulate the decision making into establishes_stacking_context(). When we paint, we start from the ICB (LayoutDocument) who always has a StackingContext and then paint the tree of StackingContexts where each node has its children sorted by z-index. This is pretty crude, but gets the basic job done. Note that this does not yet support hit testing; hit testing is still done using a naive treewalk from the root.
2020-06-15 17:29:35 +02:00
LibWeb: Move StackingContext and PaintPhase into the Painting namespace
2022-03-10 02:13:28 +01:00
namespace Web::Painting {
LibWeb: Respect CSS z-index property while painting To support z-ordering when painting, the layout tree now has a parallel sparse tree of stacking contexts. The rules for which layout boxes establish a stacking context are a bit complex, but the intent is to encapsulate the decision making into establishes_stacking_context(). When we paint, we start from the ICB (LayoutDocument) who always has a StackingContext and then paint the tree of StackingContexts where each node has its children sorted by z-index. This is pretty crude, but gets the basic job done. Note that this does not yet support hit testing; hit testing is still done using a naive treewalk from the root.
2020-06-15 17:29:35 +02:00
LibWeb: Make StackingContext point to paint tree instead of layout tree Eventually we should not need the layout tree for anything when painting and this code will only look at the paint tree. For now, this is just another step in that direction.
2023-08-19 15:20:45 +02:00
static void paint_node(Paintable const& paintable, PaintContext& context, PaintPhase phase)
LibWeb: Let Paintable perform the painting This patch adds a bunch of Paintable subclasses, each corresponding to the Layout::Node subclasses that had a paint() override. All painting logic is moved from layout nodes into their corresponding paintables. Paintables are now created by asking a Layout::Box to produce one: static NonnullOwnPtr<Paintable> Layout::Box::create_paintable() Note that inline nodes still have their painting logic. Since they are not boxes, and all paintables have a corresponding box, we'll need to come up with some other solution for them.
2022-03-10 14:02:25 +01:00
{
LibWeb: Apply CSS `clip` property to an element as well as its children d06d4eb made the `clip` property apply to children of an absolute- positioned element, but caused it not to be applied to the element the property was applied to directly. To fix this, apply the clip in new `before_paint()` and `after_paint()` functions. Doing so keeps painter state from leaking from `paint()`, but still allows subclasses of `PaintableBox` clip their contents correctly without repeating the application of the clip rectangle.
2023-08-31 17:08:45 -05:00
paintable.before_paint(context, phase);
LibWeb: Make StackingContext point to paint tree instead of layout tree Eventually we should not need the layout tree for anything when painting and this code will only look at the paint tree. For now, this is just another step in that direction.
2023-08-19 15:20:45 +02:00
paintable.paint(context, phase);
LibWeb: Apply CSS `clip` property to an element as well as its children d06d4eb made the `clip` property apply to children of an absolute- positioned element, but caused it not to be applied to the element the property was applied to directly. To fix this, apply the clip in new `before_paint()` and `after_paint()` functions. Doing so keeps painter state from leaking from `paint()`, but still allows subclasses of `PaintableBox` clip their contents correctly without repeating the application of the clip rectangle.
2023-08-31 17:08:45 -05:00
paintable.after_paint(context, phase);
LibWeb: Let Paintable perform the painting This patch adds a bunch of Paintable subclasses, each corresponding to the Layout::Node subclasses that had a paint() override. All painting logic is moved from layout nodes into their corresponding paintables. Paintables are now created by asking a Layout::Box to produce one: static NonnullOwnPtr<Paintable> Layout::Box::create_paintable() Note that inline nodes still have their painting logic. Since they are not boxes, and all paintables have a corresponding box, we'll need to come up with some other solution for them.
2022-03-10 14:02:25 +01:00
}
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
StackingContext::StackingContext(PaintableBox& paintable, StackingContext* parent, size_t index_in_tree_order)
LibWeb: Allow inline nodes to establish a stacking context With this change, a stacking context can be established by any paintable, including inline paintables. The stacking context traversal is updated to remove the assumption that the stacking context root is paintable box.
2024-01-03 02:40:31 +01:00
: m_paintable(paintable)
LibWeb: Respect CSS z-index property while painting To support z-ordering when painting, the layout tree now has a parallel sparse tree of stacking contexts. The rules for which layout boxes establish a stacking context are a bit complex, but the intent is to encapsulate the decision making into establishes_stacking_context(). When we paint, we start from the ICB (LayoutDocument) who always has a StackingContext and then paint the tree of StackingContexts where each node has its children sorted by z-index. This is pretty crude, but gets the basic job done. Note that this does not yet support hit testing; hit testing is still done using a naive treewalk from the root.
2020-06-15 17:29:35 +02:00
, m_parent(parent)
LibWeb: Make StackingContext sorting a lot faster Stacking contexts are sorted after building a tree of them. They are sorted by z-index first, DOM tree order second. Sorting was previously *very* slow on pages with many stacking contexts. That was because the sort() function used Node::is_before() in the quick_sort comparator to see if one StackingContext was before another. is_before() does tree traversal and can take quite a long time per call. This patch avoids all that by letting StackingContext know its index among all StackingContexts within the same document in tree order. There's a noticeable snappiness increase on the CSS-FLEXBOX-1 spec page, for instance. :^)
2023-06-02 12:01:14 +02:00
, m_index_in_tree_order(index_in_tree_order)
LibWeb: Respect CSS z-index property while painting To support z-ordering when painting, the layout tree now has a parallel sparse tree of stacking contexts. The rules for which layout boxes establish a stacking context are a bit complex, but the intent is to encapsulate the decision making into establishes_stacking_context(). When we paint, we start from the ICB (LayoutDocument) who always has a StackingContext and then paint the tree of StackingContexts where each node has its children sorted by z-index. This is pretty crude, but gets the basic job done. Note that this does not yet support hit testing; hit testing is still done using a naive treewalk from the root.
2020-06-15 17:29:35 +02:00
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(m_parent != this);
LibWeb: Sort stacking context tree once, after fully building it Instead of calling quick_sort() every time a StackingContext child is added to a parent, we now do a single pass of sorting work after the full StackingContext tree has been built. Before this change, the quick_sort() was ~13.5% of the profile while hovering links on GitHub in the Browser. After the change, it's down to ~0.6%. Pretty good! :^)
2022-03-13 16:19:54 +01:00
if (m_parent)
LibWeb: Respect CSS z-index property while painting To support z-ordering when painting, the layout tree now has a parallel sparse tree of stacking contexts. The rules for which layout boxes establish a stacking context are a bit complex, but the intent is to encapsulate the decision making into establishes_stacking_context(). When we paint, we start from the ICB (LayoutDocument) who always has a StackingContext and then paint the tree of StackingContexts where each node has its children sorted by z-index. This is pretty crude, but gets the basic job done. Note that this does not yet support hit testing; hit testing is still done using a naive treewalk from the root.
2020-06-15 17:29:35 +02:00
m_parent->m_children.append(this);
LibWeb: Sort stacking context tree once, after fully building it Instead of calling quick_sort() every time a StackingContext child is added to a parent, we now do a single pass of sorting work after the full StackingContext tree has been built. Before this change, the quick_sort() was ~13.5% of the profile while hovering links on GitHub in the Browser. After the change, it's down to ~0.6%. Pretty good! :^)
2022-03-13 16:19:54 +01:00
}
LibWeb: Respect CSS z-index property while painting To support z-ordering when painting, the layout tree now has a parallel sparse tree of stacking contexts. The rules for which layout boxes establish a stacking context are a bit complex, but the intent is to encapsulate the decision making into establishes_stacking_context(). When we paint, we start from the ICB (LayoutDocument) who always has a StackingContext and then paint the tree of StackingContexts where each node has its children sorted by z-index. This is pretty crude, but gets the basic job done. Note that this does not yet support hit testing; hit testing is still done using a naive treewalk from the root.
2020-06-15 17:29:35 +02:00
LibWeb: Sort stacking context tree once, after fully building it Instead of calling quick_sort() every time a StackingContext child is added to a parent, we now do a single pass of sorting work after the full StackingContext tree has been built. Before this change, the quick_sort() was ~13.5% of the profile while hovering links on GitHub in the Browser. After the change, it's down to ~0.6%. Pretty good! :^)
2022-03-13 16:19:54 +01:00
void StackingContext::sort()
{
quick_sort(m_children, [](auto& a, auto& b) {
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
auto a_z_index = a->paintable_box().computed_values().z_index().value_or(0);
auto b_z_index = b->paintable_box().computed_values().z_index().value_or(0);
LibWeb: Sort stacking context tree once, after fully building it Instead of calling quick_sort() every time a StackingContext child is added to a parent, we now do a single pass of sorting work after the full StackingContext tree has been built. Before this change, the quick_sort() was ~13.5% of the profile while hovering links on GitHub in the Browser. After the change, it's down to ~0.6%. Pretty good! :^)
2022-03-13 16:19:54 +01:00
if (a_z_index == b_z_index)
LibWeb: Make StackingContext sorting a lot faster Stacking contexts are sorted after building a tree of them. They are sorted by z-index first, DOM tree order second. Sorting was previously *very* slow on pages with many stacking contexts. That was because the sort() function used Node::is_before() in the quick_sort comparator to see if one StackingContext was before another. is_before() does tree traversal and can take quite a long time per call. This patch avoids all that by letting StackingContext know its index among all StackingContexts within the same document in tree order. There's a noticeable snappiness increase on the CSS-FLEXBOX-1 spec page, for instance. :^)
2023-06-02 12:01:14 +02:00
return a->m_index_in_tree_order < b->m_index_in_tree_order;
LibWeb: Sort stacking context tree once, after fully building it Instead of calling quick_sort() every time a StackingContext child is added to a parent, we now do a single pass of sorting work after the full StackingContext tree has been built. Before this change, the quick_sort() was ~13.5% of the profile while hovering links on GitHub in the Browser. After the change, it's down to ~0.6%. Pretty good! :^)
2022-03-13 16:19:54 +01:00
return a_z_index < b_z_index;
});
for (auto* child : m_children)
child->sort();
LibWeb: Respect CSS z-index property while painting To support z-ordering when painting, the layout tree now has a parallel sparse tree of stacking contexts. The rules for which layout boxes establish a stacking context are a bit complex, but the intent is to encapsulate the decision making into establishes_stacking_context(). When we paint, we start from the ICB (LayoutDocument) who always has a StackingContext and then paint the tree of StackingContexts where each node has its children sorted by z-index. This is pretty crude, but gets the basic job done. Note that this does not yet support hit testing; hit testing is still done using a naive treewalk from the root.
2020-06-15 17:29:35 +02:00
}
LibWeb: Verify in runtime that stacking context is not painted twice Duplicated stacking context painting is easy to introduce because of a bit complicated traversal order and very painful to debug.
2024-04-29 17:33:50 +02:00
void StackingContext::set_last_paint_generation_id(u64 generation_id)
{
LibWeb: Log error instead of crashing if stacking context painted twice Turns out this mistake happens fairly often, so it is more preferable to log message and proceed instead of crashing.
2024-05-05 17:44:23 +02:00
if (m_last_paint_generation_id.has_value() && m_last_paint_generation_id.value() >= generation_id) {
dbgln("FIXME: Painting commands are recorded twice for stacking context: {}", m_paintable->layout_node().debug_description());
}
LibWeb: Verify in runtime that stacking context is not painted twice Duplicated stacking context painting is easy to introduce because of a bit complicated traversal order and very painful to debug.
2024-04-29 17:33:50 +02:00
m_last_paint_generation_id = generation_id;
}
LibWeb: Apply overflow: hidden to all (relevant) child paint phases Previously, before/after_children_paint() was only called for the "Foreground" paint phase, this meant the backgrounds and other features of child nodes of a element with overflow: hidden were not clipped.
2022-07-19 11:02:56 +01:00
static PaintPhase to_paint_phase(StackingContext::StackingContextPaintPhase phase)
LibWeb: Respect CSS z-index property while painting To support z-ordering when painting, the layout tree now has a parallel sparse tree of stacking contexts. The rules for which layout boxes establish a stacking context are a bit complex, but the intent is to encapsulate the decision making into establishes_stacking_context(). When we paint, we start from the ICB (LayoutDocument) who always has a StackingContext and then paint the tree of StackingContexts where each node has its children sorted by z-index. This is pretty crude, but gets the basic job done. Note that this does not yet support hit testing; hit testing is still done using a naive treewalk from the root.
2020-06-15 17:29:35 +02:00
{
Everywhere: Fix a variety of typos Spelling fixes found by `codespell`.
2022-09-09 14:53:53 -07:00
// There are not a fully correct mapping since some stacking context phases are combined.
LibWeb: Apply overflow: hidden to all (relevant) child paint phases Previously, before/after_children_paint() was only called for the "Foreground" paint phase, this meant the backgrounds and other features of child nodes of a element with overflow: hidden were not clipped.
2022-07-19 11:02:56 +01:00
switch (phase) {
case StackingContext::StackingContextPaintPhase::Floats:
case StackingContext::StackingContextPaintPhase::BackgroundAndBordersForInlineLevelAndReplaced:
case StackingContext::StackingContextPaintPhase::BackgroundAndBorders:
return PaintPhase::Background;
case StackingContext::StackingContextPaintPhase::Foreground:
return PaintPhase::Foreground;
case StackingContext::StackingContextPaintPhase::FocusAndOverlay:
return PaintPhase::Overlay;
default:
VERIFY_NOT_REACHED();
LibWeb: Let Paintable perform the painting This patch adds a bunch of Paintable subclasses, each corresponding to the Layout::Node subclasses that had a paint() override. All painting logic is moved from layout nodes into their corresponding paintables. Paintables are now created by asking a Layout::Box to produce one: static NonnullOwnPtr<Paintable> Layout::Box::create_paintable() Note that inline nodes still have their painting logic. Since they are not boxes, and all paintables have a corresponding box, we'll need to come up with some other solution for them.
2022-03-10 14:02:25 +01:00
}
LibWeb: Apply overflow: hidden to all (relevant) child paint phases Previously, before/after_children_paint() was only called for the "Foreground" paint phase, this meant the backgrounds and other features of child nodes of a element with overflow: hidden were not clipped.
2022-07-19 11:02:56 +01:00
}
LibWeb: Make StackingContext functions `static` where possible These don't need to be member functions, and this will make it easier to use these to paint <mask> elements (into an off-screen mask bitmap).
2023-09-10 13:41:00 +01:00
void StackingContext::paint_node_as_stacking_context(Paintable const& paintable, PaintContext& context)
LibWeb: Treat grid item as it creates stacking context during painting Grid specification https://www.w3.org/TR/css-grid-2/#z-order defines special painting order for grid items which should be the same as for defined for inline-blocks in CSS2.
2023-08-20 19:42:54 +02:00
{
LibWeb: Don't allow SVG boxes to create a stacking context Prior to this change, SVGs were following the CSS painting order, which means SVG boxes could have established stacking context and be sorted by z-index. There is a section in the spec that defines what kind of SVG boxes should create a stacking context https://www.w3.org/TR/SVG2/render.html#EstablishingStackingContex Although this spec is marked as a draft and rendering order described in this spec does not match what other engines do. This spec issue comment has a good summary of what other engines actually do regarding painting order https://github.com/w3c/svgwg/issues/264#issuecomment-246432360 "as long as you're relying solely on the default z-index (which SVG1 does, by definition), nothing ever changes order when you apply opacity/filter/etc". This change aligns our implementation with other engines by forbidding SVGs to create a formatting context and painting them in order they are defined in tree tree.
2024-10-09 02:57:57 +02:00
if (paintable.layout_node().is_svg_svg_box()) {
paint_svg(context, static_cast<PaintableBox const&>(paintable), PaintPhase::Foreground);
return;
}
LibWeb: Remove superfluous VERIFY from StackingContext We just checked if it's an SVG box, let's not do it again.
2024-10-30 23:47:55 +01:00
LibWeb: Treat grid item as it creates stacking context during painting Grid specification https://www.w3.org/TR/css-grid-2/#z-order defines special painting order for grid items which should be the same as for defined for inline-blocks in CSS2.
2023-08-20 19:42:54 +02:00
paint_node(paintable, context, PaintPhase::Background);
paint_node(paintable, context, PaintPhase::Border);
paint_descendants(context, paintable, StackingContextPaintPhase::BackgroundAndBorders);
paint_descendants(context, paintable, StackingContextPaintPhase::Floats);
paint_descendants(context, paintable, StackingContextPaintPhase::BackgroundAndBordersForInlineLevelAndReplaced);
paint_node(paintable, context, PaintPhase::Foreground);
paint_descendants(context, paintable, StackingContextPaintPhase::Foreground);
paint_node(paintable, context, PaintPhase::Outline);
paint_node(paintable, context, PaintPhase::Overlay);
paint_descendants(context, paintable, StackingContextPaintPhase::FocusAndOverlay);
}
LibWeb: Don't allow SVG boxes to create a stacking context Prior to this change, SVGs were following the CSS painting order, which means SVG boxes could have established stacking context and be sorted by z-index. There is a section in the spec that defines what kind of SVG boxes should create a stacking context https://www.w3.org/TR/SVG2/render.html#EstablishingStackingContex Although this spec is marked as a draft and rendering order described in this spec does not match what other engines do. This spec issue comment has a good summary of what other engines actually do regarding painting order https://github.com/w3c/svgwg/issues/264#issuecomment-246432360 "as long as you're relying solely on the default z-index (which SVG1 does, by definition), nothing ever changes order when you apply opacity/filter/etc". This change aligns our implementation with other engines by forbidding SVGs to create a formatting context and painting them in order they are defined in tree tree.
2024-10-09 02:57:57 +02:00
void StackingContext::paint_svg(PaintContext& context, PaintableBox const& paintable, PaintPhase phase)
{
if (phase != PaintPhase::Foreground)
return;
paintable.apply_clip_overflow_rect(context, PaintPhase::Foreground);
paint_node(paintable, context, PaintPhase::Background);
paint_node(paintable, context, PaintPhase::Border);
LibWeb: Make SVGs respect their CSS transforms
2024-11-22 21:04:18 +01:00
SVGSVGPaintable::paint_svg_box(context, paintable, phase);
LibWeb: Don't allow SVG boxes to create a stacking context Prior to this change, SVGs were following the CSS painting order, which means SVG boxes could have established stacking context and be sorted by z-index. There is a section in the spec that defines what kind of SVG boxes should create a stacking context https://www.w3.org/TR/SVG2/render.html#EstablishingStackingContex Although this spec is marked as a draft and rendering order described in this spec does not match what other engines do. This spec issue comment has a good summary of what other engines actually do regarding painting order https://github.com/w3c/svgwg/issues/264#issuecomment-246432360 "as long as you're relying solely on the default z-index (which SVG1 does, by definition), nothing ever changes order when you apply opacity/filter/etc". This change aligns our implementation with other engines by forbidding SVGs to create a formatting context and painting them in order they are defined in tree tree.
2024-10-09 02:57:57 +02:00
paintable.clear_clip_overflow_rect(context, PaintPhase::Foreground);
}
LibWeb: Make StackingContext functions `static` where possible These don't need to be member functions, and this will make it easier to use these to paint <mask> elements (into an off-screen mask bitmap).
2023-09-10 13:41:00 +01:00
void StackingContext::paint_descendants(PaintContext& context, Paintable const& paintable, StackingContextPaintPhase phase)
LibWeb: Apply overflow: hidden to all (relevant) child paint phases Previously, before/after_children_paint() was only called for the "Foreground" paint phase, this meant the backgrounds and other features of child nodes of a element with overflow: hidden were not clipped.
2022-07-19 11:02:56 +01:00
{
LibWeb: Make StackingContext point to paint tree instead of layout tree Eventually we should not need the layout tree for anything when painting and this code will only look at the paint tree. For now, this is just another step in that direction.
2023-08-19 15:20:45 +02:00
paintable.before_children_paint(context, to_paint_phase(phase));
LibWeb: Call before/after children_paint on parent in StackingContext When it is called inside `box.for_each_child`, then it may not be called for the root element. By missing `SVGSVGBox::before_children_paint` the svg context is not created
2021-08-01 16:24:59 +02:00
LibWeb: Make StackingContext functions `static` where possible These don't need to be member functions, and this will make it easier to use these to paint <mask> elements (into an off-screen mask bitmap).
2023-09-10 13:41:00 +01:00
paintable.for_each_child([&context, phase](auto& child) {
LibWeb: Do not require box to be positioned to create stacking context Instead of implementing stacking context painting order exactly as it is defined in CSS2.2 "Appendix E. Elaborate description of Stacking Contexts" we need to account for changes in the latest standards where a box can establish a stacking context without being positioned, for example, by having an opacity different from 1. Fixes https://github.com/SerenityOS/serenity/issues/21137
2024-01-02 20:05:35 +01:00
auto const& z_index = child.computed_values().z_index();
LibWeb: Skip positioned children in paint_descendants() Positioned descendants are now handled entirely by paint_internal() so we can just skip over positioned children in paint_descendants(). This avoids drawing the same boxes multiple times.
2022-10-23 23:31:08 +02:00
LibWeb: Don't allow SVG boxes to create a stacking context Prior to this change, SVGs were following the CSS painting order, which means SVG boxes could have established stacking context and be sorted by z-index. There is a section in the spec that defines what kind of SVG boxes should create a stacking context https://www.w3.org/TR/SVG2/render.html#EstablishingStackingContex Although this spec is marked as a draft and rendering order described in this spec does not match what other engines do. This spec issue comment has a good summary of what other engines actually do regarding painting order https://github.com/w3c/svgwg/issues/264#issuecomment-246432360 "as long as you're relying solely on the default z-index (which SVG1 does, by definition), nothing ever changes order when you apply opacity/filter/etc". This change aligns our implementation with other engines by forbidding SVGs to create a formatting context and painting them in order they are defined in tree tree.
2024-10-09 02:57:57 +02:00
if (child.layout_node().is_svg_svg_box()) {
paint_svg(context, static_cast<PaintableBox const&>(child), to_paint_phase(phase));
return IterationDecision::Continue;
}
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
if (child.has_stacking_context())
LibWeb: Prevent painting grid items twice as a stacking context We paint grid item nodes as a stacking context when they have no `z-index` style set. However, a grid item could already have a stacking context established - for example, when the `filter` style is applied. This causes these nodes to be drawn twice. Skip painting grid item nodes if a stacking context is already present.
2024-10-30 23:48:34 +01:00
return IterationDecision::Continue;
LibWeb: Treat grid item as it creates stacking context during painting Grid specification https://www.w3.org/TR/css-grid-2/#z-order defines special painting order for grid items which should be the same as for defined for inline-blocks in CSS2.
2023-08-20 19:42:54 +02:00
// NOTE: Grid specification https://www.w3.org/TR/css-grid-2/#z-order says that grid items should be treated
// the same way as CSS2 defines for inline-blocks:
// "For each one of these, treat the element as if it created a new stacking context, but any positioned
// descendants and descendants which actually create a new stacking context should be considered part of
// the parent stacking context, not this new one."
LibWeb: Do not require box to be positioned to create stacking context Instead of implementing stacking context painting order exactly as it is defined in CSS2.2 "Appendix E. Elaborate description of Stacking Contexts" we need to account for changes in the latest standards where a box can establish a stacking context without being positioned, for example, by having an opacity different from 1. Fixes https://github.com/SerenityOS/serenity/issues/21137
2024-01-02 20:05:35 +01:00
auto should_be_treated_as_stacking_context = child.layout_node().is_grid_item() && !z_index.has_value();
LibWeb: Treat grid item as it creates stacking context during painting Grid specification https://www.w3.org/TR/css-grid-2/#z-order defines special painting order for grid items which should be the same as for defined for inline-blocks in CSS2.
2023-08-20 19:42:54 +02:00
if (should_be_treated_as_stacking_context) {
// FIXME: This may not be fully correct with respect to the paint phases.
if (phase == StackingContextPaintPhase::Foreground)
paint_node_as_stacking_context(child, context);
LibWeb: Use `IterationDecision` in single level Node iteration methods `Node::for_each_child()` and `Node::for_each_child_of_type()` callbacks now return an `IterationDecision`, which allows us to break early if required.
2024-05-04 14:59:52 +01:00
return IterationDecision::Continue;
LibWeb: Treat grid item as it creates stacking context during painting Grid specification https://www.w3.org/TR/css-grid-2/#z-order defines special painting order for grid items which should be the same as for defined for inline-blocks in CSS2.
2023-08-20 19:42:54 +02:00
}
LibWeb: Fix paint recording to stop visiting stacking context twice ...if its box is positioned and has z-index=0.
2024-04-29 17:00:49 +02:00
if (child.is_positioned() && z_index.value_or(0) == 0)
LibWeb: Use `IterationDecision` in single level Node iteration methods `Node::for_each_child()` and `Node::for_each_child_of_type()` callbacks now return an `IterationDecision`, which allows us to break early if required.
2024-05-04 14:59:52 +01:00
return IterationDecision::Continue;
LibWeb: Do not require box to be positioned to create stacking context Instead of implementing stacking context painting order exactly as it is defined in CSS2.2 "Appendix E. Elaborate description of Stacking Contexts" we need to account for changes in the latest standards where a box can establish a stacking context without being positioned, for example, by having an opacity different from 1. Fixes https://github.com/SerenityOS/serenity/issues/21137
2024-01-02 20:05:35 +01:00
LibWeb: Fix bogus ReplacedBox type check in StackingContext We should be asking if the layout node is a ReplacedBox, not the paintable.
2024-03-02 09:54:12 +01:00
bool child_is_inline_or_replaced = child.is_inline() || is<Layout::ReplacedBox>(child.layout_node());
LibWeb: Make painting order more spec-compliant Now our painting order inside stacking contexts is closer to the algorithm specified by CSS 2.1 (see section 9.9 and Appendix E)
2021-05-07 19:03:25 +03:00
switch (phase) {
case StackingContextPaintPhase::BackgroundAndBorders:
LibWeb: Update StackingContext::paint_descendants() for new rule Since positioned elements no longer automatically create stacking contexts, we can't rely on this assumption when painting descendants of a stacking context. In this commit, we fix an issue that manifested as a failure to Gfx::Painter::restore() in the "Overlay" paint phase. What happened was that a CSS clip was being applied in the "Background" paint phase, and then unapplied in the "Overlay" phase. Due to bogus checks in paint_descendants(), the "Background" phase never ran for positioned elements, but the "Overlay" phase did. The check for positioned elements was bogus in the first place and had never actually worked before, since we would always skip over positioned descendants due to them having stacking contexts.
2022-10-23 18:15:14 +02:00
if (!child_is_inline_or_replaced && !child.is_floating()) {
LibWeb: Let Paintable perform the painting This patch adds a bunch of Paintable subclasses, each corresponding to the Layout::Node subclasses that had a paint() override. All painting logic is moved from layout nodes into their corresponding paintables. Paintables are now created by asking a Layout::Box to produce one: static NonnullOwnPtr<Paintable> Layout::Box::create_paintable() Note that inline nodes still have their painting logic. Since they are not boxes, and all paintables have a corresponding box, we'll need to come up with some other solution for them.
2022-03-10 14:02:25 +01:00
paint_node(child, context, PaintPhase::Background);
LibWeb: Apply scroll offset and clip rectangle to table borders Moves paint_table_borders() call into PaintableBox::paint() to make scroll offset and clip rectangle of enclosing scrollable be applied in ::before_paint().
2024-07-30 13:41:48 +03:00
paint_node(child, context, PaintPhase::Border);
LibWeb: Make painting order more spec-compliant Now our painting order inside stacking contexts is closer to the algorithm specified by CSS 2.1 (see section 9.9 and Appendix E)
2021-05-07 19:03:25 +03:00
paint_descendants(context, child, phase);
LibWeb: Apply scroll offset and clip rectangle to table borders Moves paint_table_borders() call into PaintableBox::paint() to make scroll offset and clip rectangle of enclosing scrollable be applied in ::before_paint().
2024-07-30 13:41:48 +03:00
paint_node(child, context, PaintPhase::TableCollapsedBorder);
LibWeb: Make painting order more spec-compliant Now our painting order inside stacking contexts is closer to the algorithm specified by CSS 2.1 (see section 9.9 and Appendix E)
2021-05-07 19:03:25 +03:00
}
break;
case StackingContextPaintPhase::Floats:
LibWeb: Update StackingContext::paint_descendants() for new rule Since positioned elements no longer automatically create stacking contexts, we can't rely on this assumption when painting descendants of a stacking context. In this commit, we fix an issue that manifested as a failure to Gfx::Painter::restore() in the "Overlay" paint phase. What happened was that a CSS clip was being applied in the "Background" paint phase, and then unapplied in the "Overlay" phase. Due to bogus checks in paint_descendants(), the "Background" phase never ran for positioned elements, but the "Overlay" phase did. The check for positioned elements was bogus in the first place and had never actually worked before, since we would always skip over positioned descendants due to them having stacking contexts.
2022-10-23 18:15:14 +02:00
if (child.is_floating()) {
paint_node(child, context, PaintPhase::Background);
paint_node(child, context, PaintPhase::Border);
paint_descendants(context, child, StackingContextPaintPhase::BackgroundAndBorders);
LibWeb: Make painting order more spec-compliant Now our painting order inside stacking contexts is closer to the algorithm specified by CSS 2.1 (see section 9.9 and Appendix E)
2021-05-07 19:03:25 +03:00
}
LibWeb: Update StackingContext::paint_descendants() for new rule Since positioned elements no longer automatically create stacking contexts, we can't rely on this assumption when painting descendants of a stacking context. In this commit, we fix an issue that manifested as a failure to Gfx::Painter::restore() in the "Overlay" paint phase. What happened was that a CSS clip was being applied in the "Background" paint phase, and then unapplied in the "Overlay" phase. Due to bogus checks in paint_descendants(), the "Background" phase never ran for positioned elements, but the "Overlay" phase did. The check for positioned elements was bogus in the first place and had never actually worked before, since we would always skip over positioned descendants due to them having stacking contexts.
2022-10-23 18:15:14 +02:00
paint_descendants(context, child, phase);
LibWeb: Make painting order more spec-compliant Now our painting order inside stacking contexts is closer to the algorithm specified by CSS 2.1 (see section 9.9 and Appendix E)
2021-05-07 19:03:25 +03:00
break;
LibWeb: Paint inline-level and replaced elements on top of floats This matches CSS 2.1 appendix E, and fixes an instance of red face border on ACID2. :^)
2022-02-14 16:39:45 +01:00
case StackingContextPaintPhase::BackgroundAndBordersForInlineLevelAndReplaced:
LibWeb: Update StackingContext::paint_descendants() for new rule Since positioned elements no longer automatically create stacking contexts, we can't rely on this assumption when painting descendants of a stacking context. In this commit, we fix an issue that manifested as a failure to Gfx::Painter::restore() in the "Overlay" paint phase. What happened was that a CSS clip was being applied in the "Background" paint phase, and then unapplied in the "Overlay" phase. Due to bogus checks in paint_descendants(), the "Background" phase never ran for positioned elements, but the "Overlay" phase did. The check for positioned elements was bogus in the first place and had never actually worked before, since we would always skip over positioned descendants due to them having stacking contexts.
2022-10-23 18:15:14 +02:00
if (child_is_inline_or_replaced) {
paint_node(child, context, PaintPhase::Background);
paint_node(child, context, PaintPhase::Border);
LibWeb: Apply scroll offset and clip rectangle to table borders Moves paint_table_borders() call into PaintableBox::paint() to make scroll offset and clip rectangle of enclosing scrollable be applied in ::before_paint().
2024-07-30 13:41:48 +03:00
paint_node(child, context, PaintPhase::TableCollapsedBorder);
LibWeb: Update StackingContext::paint_descendants() for new rule Since positioned elements no longer automatically create stacking contexts, we can't rely on this assumption when painting descendants of a stacking context. In this commit, we fix an issue that manifested as a failure to Gfx::Painter::restore() in the "Overlay" paint phase. What happened was that a CSS clip was being applied in the "Background" paint phase, and then unapplied in the "Overlay" phase. Due to bogus checks in paint_descendants(), the "Background" phase never ran for positioned elements, but the "Overlay" phase did. The check for positioned elements was bogus in the first place and had never actually worked before, since we would always skip over positioned descendants due to them having stacking contexts.
2022-10-23 18:15:14 +02:00
paint_descendants(context, child, StackingContextPaintPhase::BackgroundAndBorders);
LibWeb: Paint inline-level and replaced elements on top of floats This matches CSS 2.1 appendix E, and fixes an instance of red face border on ACID2. :^)
2022-02-14 16:39:45 +01:00
}
LibWeb: Update StackingContext::paint_descendants() for new rule Since positioned elements no longer automatically create stacking contexts, we can't rely on this assumption when painting descendants of a stacking context. In this commit, we fix an issue that manifested as a failure to Gfx::Painter::restore() in the "Overlay" paint phase. What happened was that a CSS clip was being applied in the "Background" paint phase, and then unapplied in the "Overlay" phase. Due to bogus checks in paint_descendants(), the "Background" phase never ran for positioned elements, but the "Overlay" phase did. The check for positioned elements was bogus in the first place and had never actually worked before, since we would always skip over positioned descendants due to them having stacking contexts.
2022-10-23 18:15:14 +02:00
paint_descendants(context, child, phase);
LibWeb: Paint inline-level and replaced elements on top of floats This matches CSS 2.1 appendix E, and fixes an instance of red face border on ACID2. :^)
2022-02-14 16:39:45 +01:00
break;
LibWeb: Make painting order more spec-compliant Now our painting order inside stacking contexts is closer to the algorithm specified by CSS 2.1 (see section 9.9 and Appendix E)
2021-05-07 19:03:25 +03:00
case StackingContextPaintPhase::Foreground:
LibWeb: Update StackingContext::paint_descendants() for new rule Since positioned elements no longer automatically create stacking contexts, we can't rely on this assumption when painting descendants of a stacking context. In this commit, we fix an issue that manifested as a failure to Gfx::Painter::restore() in the "Overlay" paint phase. What happened was that a CSS clip was being applied in the "Background" paint phase, and then unapplied in the "Overlay" phase. Due to bogus checks in paint_descendants(), the "Background" phase never ran for positioned elements, but the "Overlay" phase did. The check for positioned elements was bogus in the first place and had never actually worked before, since we would always skip over positioned descendants due to them having stacking contexts.
2022-10-23 18:15:14 +02:00
paint_node(child, context, PaintPhase::Foreground);
paint_descendants(context, child, phase);
LibWeb: Make painting order more spec-compliant Now our painting order inside stacking contexts is closer to the algorithm specified by CSS 2.1 (see section 9.9 and Appendix E)
2021-05-07 19:03:25 +03:00
break;
case StackingContextPaintPhase::FocusAndOverlay:
LibWeb: Implement the CSS `outline` property :^) ...along with `outline-color`, `outline-style`, and `outline-width`. This re-uses the existing border-painting code, which seems to work well enough! This replaces the previous code for drawing focus-outlines, with generic outline painting for any elements that want it. Focus outlines are now instead supported by this code in Default.css: ```css :focus-visible { outline: auto; } ```
2023-08-02 17:24:14 +01:00
paint_node(child, context, PaintPhase::Outline);
LibWeb: Let Paintable perform the painting This patch adds a bunch of Paintable subclasses, each corresponding to the Layout::Node subclasses that had a paint() override. All painting logic is moved from layout nodes into their corresponding paintables. Paintables are now created by asking a Layout::Box to produce one: static NonnullOwnPtr<Paintable> Layout::Box::create_paintable() Note that inline nodes still have their painting logic. Since they are not boxes, and all paintables have a corresponding box, we'll need to come up with some other solution for them.
2022-03-10 14:02:25 +01:00
paint_node(child, context, PaintPhase::Overlay);
LibWeb: Make painting order more spec-compliant Now our painting order inside stacking contexts is closer to the algorithm specified by CSS 2.1 (see section 9.9 and Appendix E)
2021-05-07 19:03:25 +03:00
paint_descendants(context, child, phase);
break;
}
LibWeb: Use `IterationDecision` in single level Node iteration methods `Node::for_each_child()` and `Node::for_each_child_of_type()` callbacks now return an `IterationDecision`, which allows us to break early if required.
2024-05-04 14:59:52 +01:00
return IterationDecision::Continue;
LibWeb: Make painting order more spec-compliant Now our painting order inside stacking contexts is closer to the algorithm specified by CSS 2.1 (see section 9.9 and Appendix E)
2021-05-07 19:03:25 +03:00
});
LibWeb: Call before/after children_paint on parent in StackingContext When it is called inside `box.for_each_child`, then it may not be called for the root element. By missing `SVGSVGBox::before_children_paint` the svg context is not created
2021-08-01 16:24:59 +02:00
LibWeb: Make StackingContext point to paint tree instead of layout tree Eventually we should not need the layout tree for anything when painting and this code will only look at the paint tree. For now, this is just another step in that direction.
2023-08-19 15:20:45 +02:00
paintable.after_children_paint(context, to_paint_phase(phase));
LibWeb: Make painting order more spec-compliant Now our painting order inside stacking contexts is closer to the algorithm specified by CSS 2.1 (see section 9.9 and Appendix E)
2021-05-07 19:03:25 +03:00
}
LibWeb: Make StackingContext functions `static` where possible These don't need to be member functions, and this will make it easier to use these to paint <mask> elements (into an off-screen mask bitmap).
2023-09-10 13:41:00 +01:00
void StackingContext::paint_child(PaintContext& context, StackingContext const& child)
LibWeb: Don't paint all stacking contexts like positioned elements Previously stacking contexts were only painted in steps 3, 8, and 9. These steps are only meant to cover positioned elements (as per https://www.w3.org/TR/CSS22/zindex.html). This meant that elements with opacity (which forms a stacking context) could end up painted above elements that actually occlude them.
2023-08-13 18:56:56 +01:00
{
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
VERIFY(!child.paintable_box().layout_node().is_svg_box());
VERIFY(!child.paintable_box().layout_node().is_svg_svg_box());
LibWeb: Don't allow SVG boxes to create a stacking context Prior to this change, SVGs were following the CSS painting order, which means SVG boxes could have established stacking context and be sorted by z-index. There is a section in the spec that defines what kind of SVG boxes should create a stacking context https://www.w3.org/TR/SVG2/render.html#EstablishingStackingContex Although this spec is marked as a draft and rendering order described in this spec does not match what other engines do. This spec issue comment has a good summary of what other engines actually do regarding painting order https://github.com/w3c/svgwg/issues/264#issuecomment-246432360 "as long as you're relying solely on the default z-index (which SVG1 does, by definition), nothing ever changes order when you apply opacity/filter/etc". This change aligns our implementation with other engines by forbidding SVGs to create a formatting context and painting them in order they are defined in tree tree.
2024-10-09 02:57:57 +02:00
LibWeb: Verify in runtime that stacking context is not painted twice Duplicated stacking context painting is easy to introduce because of a bit complicated traversal order and very painful to debug.
2024-04-29 17:33:50 +02:00
const_cast<StackingContext&>(child).set_last_paint_generation_id(context.paint_generation_id());
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
auto parent_paintable = child.paintable_box().parent();
LibWeb: Don't paint all stacking contexts like positioned elements Previously stacking contexts were only painted in steps 3, 8, and 9. These steps are only meant to cover positioned elements (as per https://www.w3.org/TR/CSS22/zindex.html). This meant that elements with opacity (which forms a stacking context) could end up painted above elements that actually occlude them.
2023-08-13 18:56:56 +01:00
if (parent_paintable)
parent_paintable->before_children_paint(context, PaintPhase::Foreground);
child.paint(context);
if (parent_paintable)
parent_paintable->after_children_paint(context, PaintPhase::Foreground);
}
LibWeb: Make StackingContext paint functions const
2022-03-10 15:44:43 +01:00
void StackingContext::paint_internal(PaintContext& context) const
LibWeb: Make painting order more spec-compliant Now our painting order inside stacking contexts is closer to the algorithm specified by CSS 2.1 (see section 9.9 and Appendix E)
2021-05-07 19:03:25 +03:00
{
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
VERIFY(!paintable_box().layout_node().is_svg_box());
if (paintable_box().layout_node().is_svg_svg_box()) {
LibWeb: Don't allow SVG boxes to create a stacking context Prior to this change, SVGs were following the CSS painting order, which means SVG boxes could have established stacking context and be sorted by z-index. There is a section in the spec that defines what kind of SVG boxes should create a stacking context https://www.w3.org/TR/SVG2/render.html#EstablishingStackingContex Although this spec is marked as a draft and rendering order described in this spec does not match what other engines do. This spec issue comment has a good summary of what other engines actually do regarding painting order https://github.com/w3c/svgwg/issues/264#issuecomment-246432360 "as long as you're relying solely on the default z-index (which SVG1 does, by definition), nothing ever changes order when you apply opacity/filter/etc". This change aligns our implementation with other engines by forbidding SVGs to create a formatting context and painting them in order they are defined in tree tree.
2024-10-09 02:57:57 +02:00
paint_svg(context, paintable_box(), PaintPhase::Foreground);
return;
}
LibWeb: Make painting order more spec-compliant Now our painting order inside stacking contexts is closer to the algorithm specified by CSS 2.1 (see section 9.9 and Appendix E)
2021-05-07 19:03:25 +03:00
// For a more elaborate description of the algorithm, see CSS 2.1 Appendix E
// Draw the background and borders for the context root (steps 1, 2)
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
paint_node(paintable_box(), context, PaintPhase::Background);
paint_node(paintable_box(), context, PaintPhase::Border);
LibWeb: Fix overflow: hidden not applying to positioned descendants This now calls before/after_child_paint() on the parent paintable of a positioned child. This allows the parent's overflow clipping to apply to the child.
2022-07-19 11:06:21 +01:00
LibWeb: Don't paint all stacking contexts like positioned elements Previously stacking contexts were only painted in steps 3, 8, and 9. These steps are only meant to cover positioned elements (as per https://www.w3.org/TR/CSS22/zindex.html). This meant that elements with opacity (which forms a stacking context) could end up painted above elements that actually occlude them.
2023-08-13 18:56:56 +01:00
// Stacking contexts formed by positioned descendants with negative z-indices (excluding 0) in z-index order
// (most negative first) then tree order. (step 3)
LibWeb: Don't ignore non-positioned stacking contexts on step 8 of paint ...traversal. We've already fixed step 3 and 9 to not filter out non-positioned stacking contexts, because modern CSS has more ways to create stacking context besides being positioned with z-index (like by using "transform", "filter" or "clip-path" properties). See following spec issue for more details https://github.com/w3c/csswg-drafts/issues/2717 Visual improvement on https://basecamp.com/
2024-10-09 03:49:49 +02:00
// Here, we treat non-positioned stacking contexts as if they were positioned, because CSS 2.0 spec does not
// account for new properties like `transform` and `opacity` that can create stacking contexts.
// https://github.com/w3c/csswg-drafts/issues/2717
LibWeb: Make painting order more spec-compliant Now our painting order inside stacking contexts is closer to the algorithm specified by CSS 2.1 (see section 9.9 and Appendix E)
2021-05-07 19:03:25 +03:00
for (auto* child : m_children) {
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
if (child->paintable_box().computed_values().z_index().has_value() && child->paintable_box().computed_values().z_index().value() < 0)
LibWeb: Don't paint all stacking contexts like positioned elements Previously stacking contexts were only painted in steps 3, 8, and 9. These steps are only meant to cover positioned elements (as per https://www.w3.org/TR/CSS22/zindex.html). This meant that elements with opacity (which forms a stacking context) could end up painted above elements that actually occlude them.
2023-08-13 18:56:56 +01:00
paint_child(context, *child);
LibWeb: Respect CSS z-index property while painting To support z-ordering when painting, the layout tree now has a parallel sparse tree of stacking contexts. The rules for which layout boxes establish a stacking context are a bit complex, but the intent is to encapsulate the decision making into establishes_stacking_context(). When we paint, we start from the ICB (LayoutDocument) who always has a StackingContext and then paint the tree of StackingContexts where each node has its children sorted by z-index. This is pretty crude, but gets the basic job done. Note that this does not yet support hit testing; hit testing is still done using a naive treewalk from the root.
2020-06-15 17:29:35 +02:00
}
LibWeb: Fix overflow: hidden not applying to positioned descendants This now calls before/after_child_paint() on the parent paintable of a positioned child. This allows the parent's overflow clipping to apply to the child.
2022-07-19 11:06:21 +01:00
LibWeb: Make painting order more spec-compliant Now our painting order inside stacking contexts is closer to the algorithm specified by CSS 2.1 (see section 9.9 and Appendix E)
2021-05-07 19:03:25 +03:00
// Draw the background and borders for block-level children (step 4)
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
paint_descendants(context, paintable_box(), StackingContextPaintPhase::BackgroundAndBorders);
LibWeb: Make painting order more spec-compliant Now our painting order inside stacking contexts is closer to the algorithm specified by CSS 2.1 (see section 9.9 and Appendix E)
2021-05-07 19:03:25 +03:00
// Draw the non-positioned floats (step 5)
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
paint_descendants(context, paintable_box(), StackingContextPaintPhase::Floats);
LibWeb: Make painting order more spec-compliant Now our painting order inside stacking contexts is closer to the algorithm specified by CSS 2.1 (see section 9.9 and Appendix E)
2021-05-07 19:03:25 +03:00
// Draw inline content, replaced content, etc. (steps 6, 7)
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
paint_descendants(context, paintable_box(), StackingContextPaintPhase::BackgroundAndBordersForInlineLevelAndReplaced);
paint_node(paintable_box(), context, PaintPhase::Foreground);
paint_descendants(context, paintable_box(), StackingContextPaintPhase::Foreground);
LibWeb: Paint positioned descendants with `z-index: auto` This "worked" before because all positioned elements would create their own stacking context. When we stopped doing this, there was nobody to actually paint positioned descendants with `z-index: auto`. This patch splits up steps 8 and 9 of the paint order algorithm and implements step 8 as a paint tree traversal. There's more to step 8 than I've implemented here, so I've left a FIXME for our future selves.
2022-10-23 18:18:58 +02:00
// Draw positioned descendants with z-index `0` or `auto` in tree order. (step 8)
LibWeb: Don't ignore non-positioned stacking contexts on step 8 of paint ...traversal. We've already fixed step 3 and 9 to not filter out non-positioned stacking contexts, because modern CSS has more ways to create stacking context besides being positioned with z-index (like by using "transform", "filter" or "clip-path" properties). See following spec issue for more details https://github.com/w3c/csswg-drafts/issues/2717 Visual improvement on https://basecamp.com/
2024-10-09 03:49:49 +02:00
// Here, we treat non-positioned stacking contexts as if they were positioned, because CSS 2.0 spec does not
// account for new properties like `transform` and `opacity` that can create stacking contexts.
// https://github.com/w3c/csswg-drafts/issues/2717
for (auto const& paintable : m_positioned_descendants_and_stacking_contexts_with_stack_level_0) {
LibWeb: Don't paint all stacking contexts like positioned elements Previously stacking contexts were only painted in steps 3, 8, and 9. These steps are only meant to cover positioned elements (as per https://www.w3.org/TR/CSS22/zindex.html). This meant that elements with opacity (which forms a stacking context) could end up painted above elements that actually occlude them.
2023-08-13 18:56:56 +01:00
// At this point, `paintable_box` is a positioned descendant with z-index: auto.
LibWeb: Paint positioned descendants with `z-index: auto` This "worked" before because all positioned elements would create their own stacking context. When we stopped doing this, there was nobody to actually paint positioned descendants with `z-index: auto`. This patch splits up steps 8 and 9 of the paint order algorithm and implements step 8 as a paint tree traversal. There's more to step 8 than I've implemented here, so I've left a FIXME for our future selves.
2022-10-23 18:18:58 +02:00
// FIXME: This is basically duplicating logic found elsewhere in this same function. Find a way to make this more elegant.
LibWeb: Fix some GCVerifier warnings
2024-04-05 13:47:48 -07:00
auto* parent_paintable = paintable->parent();
LibWeb: Use rect of containing block instead of parent to clip overflow Move overflow clipping from `before_children_paint` into separate method and call this method on containing block instead of parent. Example that got fixed: ```html <!DOCTYPE html><html><head><style> * { border: 2px solid black; } body { overflow: hidden; } .inner { position: absolute; width: 100px; height: 100px; background: lime; } </style></head><body><div class=inner></div> ```
2023-01-25 04:50:14 +03:00
if (parent_paintable)
parent_paintable->before_children_paint(context, PaintPhase::Foreground);
LibWeb: Fix some GCVerifier warnings
2024-04-05 13:47:48 -07:00
if (auto* child = paintable->stacking_context()) {
LibWeb: Don't paint all stacking contexts like positioned elements Previously stacking contexts were only painted in steps 3, 8, and 9. These steps are only meant to cover positioned elements (as per https://www.w3.org/TR/CSS22/zindex.html). This meant that elements with opacity (which forms a stacking context) could end up painted above elements that actually occlude them.
2023-08-13 18:56:56 +01:00
paint_child(context, *child);
} else {
LibWeb: Treat grid item as it creates stacking context during painting Grid specification https://www.w3.org/TR/css-grid-2/#z-order defines special painting order for grid items which should be the same as for defined for inline-blocks in CSS2.
2023-08-20 19:42:54 +02:00
paint_node_as_stacking_context(paintable, context);
LibWeb: Don't paint all stacking contexts like positioned elements Previously stacking contexts were only painted in steps 3, 8, and 9. These steps are only meant to cover positioned elements (as per https://www.w3.org/TR/CSS22/zindex.html). This meant that elements with opacity (which forms a stacking context) could end up painted above elements that actually occlude them.
2023-08-13 18:56:56 +01:00
}
LibWeb: Use rect of containing block instead of parent to clip overflow Move overflow clipping from `before_children_paint` into separate method and call this method on containing block instead of parent. Example that got fixed: ```html <!DOCTYPE html><html><head><style> * { border: 2px solid black; } body { overflow: hidden; } .inner { position: absolute; width: 100px; height: 100px; background: lime; } </style></head><body><div class=inner></div> ```
2023-01-25 04:50:14 +03:00
if (parent_paintable)
parent_paintable->after_children_paint(context, PaintPhase::Foreground);
LibWeb: Use a precalculated list of positioned descendants for painting This allows us to avoid the need for costly traversals to gather boxes that have been saved during the construction of the stacking context tree. No behavior change intended.
2024-03-02 18:36:52 +01:00
};
LibWeb: Paint positioned descendants with `z-index: auto` This "worked" before because all positioned elements would create their own stacking context. When we stopped doing this, there was nobody to actually paint positioned descendants with `z-index: auto`. This patch splits up steps 8 and 9 of the paint order algorithm and implements step 8 as a paint tree traversal. There's more to step 8 than I've implemented here, so I've left a FIXME for our future selves.
2022-10-23 18:18:58 +02:00
LibWeb: Don't paint all stacking contexts like positioned elements Previously stacking contexts were only painted in steps 3, 8, and 9. These steps are only meant to cover positioned elements (as per https://www.w3.org/TR/CSS22/zindex.html). This meant that elements with opacity (which forms a stacking context) could end up painted above elements that actually occlude them.
2023-08-13 18:56:56 +01:00
// Stacking contexts formed by positioned descendants with z-indices greater than or equal to 1 in z-index order
// (smallest first) then tree order. (Step 9)
LibWeb: Don't ignore non-positioned stacking contexts on step 8 of paint ...traversal. We've already fixed step 3 and 9 to not filter out non-positioned stacking contexts, because modern CSS has more ways to create stacking context besides being positioned with z-index (like by using "transform", "filter" or "clip-path" properties). See following spec issue for more details https://github.com/w3c/csswg-drafts/issues/2717 Visual improvement on https://basecamp.com/
2024-10-09 03:49:49 +02:00
// Here, we treat non-positioned stacking contexts as if they were positioned, because CSS 2.0 spec does not
// account for new properties like `transform` and `opacity` that can create stacking contexts.
// https://github.com/w3c/csswg-drafts/issues/2717
LibWeb: Respect CSS z-index property while painting To support z-ordering when painting, the layout tree now has a parallel sparse tree of stacking contexts. The rules for which layout boxes establish a stacking context are a bit complex, but the intent is to encapsulate the decision making into establishes_stacking_context(). When we paint, we start from the ICB (LayoutDocument) who always has a StackingContext and then paint the tree of StackingContexts where each node has its children sorted by z-index. This is pretty crude, but gets the basic job done. Note that this does not yet support hit testing; hit testing is still done using a naive treewalk from the root.
2020-06-15 17:29:35 +02:00
for (auto* child : m_children) {
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
if (child->paintable_box().computed_values().z_index().has_value() && child->paintable_box().computed_values().z_index().value() >= 1)
LibWeb: Don't paint all stacking contexts like positioned elements Previously stacking contexts were only painted in steps 3, 8, and 9. These steps are only meant to cover positioned elements (as per https://www.w3.org/TR/CSS22/zindex.html). This meant that elements with opacity (which forms a stacking context) could end up painted above elements that actually occlude them.
2023-08-13 18:56:56 +01:00
paint_child(context, *child);
LibWeb: Respect CSS z-index property while painting To support z-ordering when painting, the layout tree now has a parallel sparse tree of stacking contexts. The rules for which layout boxes establish a stacking context are a bit complex, but the intent is to encapsulate the decision making into establishes_stacking_context(). When we paint, we start from the ICB (LayoutDocument) who always has a StackingContext and then paint the tree of StackingContexts where each node has its children sorted by z-index. This is pretty crude, but gets the basic job done. Note that this does not yet support hit testing; hit testing is still done using a naive treewalk from the root.
2020-06-15 17:29:35 +02:00
}
LibWeb: Make painting order more spec-compliant Now our painting order inside stacking contexts is closer to the algorithm specified by CSS 2.1 (see section 9.9 and Appendix E)
2021-05-07 19:03:25 +03:00
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
paint_node(paintable_box(), context, PaintPhase::Outline);
LibWeb+WebContent+WebWorker: Add an option to skip painting the overlay This will allow the Inspector to take a screenshot of a DOM node without the overlay which renders the inspected node outline / box data.
2023-12-06 11:49:45 -05:00
if (context.should_paint_overlay()) {
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
paint_node(paintable_box(), context, PaintPhase::Overlay);
paint_descendants(context, paintable_box(), StackingContextPaintPhase::FocusAndOverlay);
LibWeb+WebContent+WebWorker: Add an option to skip painting the overlay This will allow the Inspector to take a screenshot of a DOM node without the overlay which renders the inspected node outline / box data.
2023-12-06 11:49:45 -05:00
}
LibWeb: Respect CSS z-index property while painting To support z-ordering when painting, the layout tree now has a parallel sparse tree of stacking contexts. The rules for which layout boxes establish a stacking context are a bit complex, but the intent is to encapsulate the decision making into establishes_stacking_context(). When we paint, we start from the ICB (LayoutDocument) who always has a StackingContext and then paint the tree of StackingContexts where each node has its children sorted by z-index. This is pretty crude, but gets the basic job done. Note that this does not yet support hit testing; hit testing is still done using a naive treewalk from the root.
2020-06-15 17:29:35 +02:00
}
LibWeb: Implement CSS transforms on stacking contexts Since there is currently no easy way to handle rotations and skews with LibGfx this only implements translation and scaling by first constructing a general 4x4 transformation matrix like outlined in the css-transforms-1 specification. This is then downgraded to a Gfx::AffineTransform in order to transform the destination rectangle used with draw_scaled_bitmap() While rotation would be nice this already looks pretty good :^)
2022-03-18 01:29:20 +01:00
// FIXME: This extracts the affine 2D part of the full transformation matrix.
// Use the whole matrix when we get better transformation support in LibGfx or use LibGL for drawing the bitmap
LibWeb: Store calculated transformation matrix on the StackingContext This is mainly so we can easily read that matrix later, but also has the benefit of only calculating the matrix once, instead of every time we paint. :^)
2022-07-19 15:18:20 +01:00
Gfx::AffineTransform StackingContext::affine_transform_matrix() const
LibWeb: Implement CSS transforms on stacking contexts Since there is currently no easy way to handle rotations and skews with LibGfx this only implements translation and scaling by first constructing a general 4x4 transformation matrix like outlined in the css-transforms-1 specification. This is then downgraded to a Gfx::AffineTransform in order to transform the destination rectangle used with draw_scaled_bitmap() While rotation would be nice this already looks pretty good :^)
2022-03-18 01:29:20 +01:00
{
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
return Gfx::extract_2d_affine_transform(paintable_box().transform());
LibWeb: Implement CSS transforms on stacking contexts Since there is currently no easy way to handle rotations and skews with LibGfx this only implements translation and scaling by first constructing a general 4x4 transformation matrix like outlined in the css-transforms-1 specification. This is then downgraded to a Gfx::AffineTransform in order to transform the destination rectangle used with draw_scaled_bitmap() While rotation would be nice this already looks pretty good :^)
2022-03-18 01:29:20 +01:00
}
LibWeb: Don't encode painting limitations in RecordingPainter API The current set of stacking context commands do not encode the information needed to correctly paint the stacking context, instead, they're based on the limitations of the current CPU renderer. Stacking contexts should be able to be transformed by an arbitrary 3D transformation matrix, not just scaled from a source to a destination rect. The `_with_mask()` stacking context also should not be separate from the regular stacking context. ```c++ push_stacking_context( bool semitransparent_or_has_non_identity_transform, float opacity, Gfx::FloatRect const& source_rect, Gfx::FloatRect const& transformed_destination_rect, Gfx::IntPoint const& painter_location); pop_stacking_context( bool semitransparent_or_has_non_identity_transform, Gfx::Painter::ScalingMode scaling_mode); push_stacking_context_with_mask( Gfx::IntRect const& paint_rect); pop_stacking_context_with_mask( Gfx::IntRect const& paint_rect, RefPtr<Gfx::Bitmap> const& mask_bitmap, Gfx::Bitmap::MaskKind mask_kind, float opacity); ``` This patch replaces this APIs with just: ```c++ push_stacking_context( float opacity, bool is_fixed_position, Gfx::IntRect const& source_paintable_rect, Gfx::IntPoint post_transform_translation, CSS::ImageRendering image_rendering, StackingContextTransform transform, Optional<StackingContextMask> mask); pop_stacking_context() ``` And moves the implementation details into the executor, this should allow future backends to implement stacking contexts without these limitations.
2023-11-18 14:23:59 +00:00
static Gfx::FloatMatrix4x4 matrix_with_scaled_translation(Gfx::FloatMatrix4x4 matrix, float scale)
LibWeb: Draw elements with opacity in a separate stacking context
2021-07-23 13:19:16 +03:00
{
LibWeb: Don't encode painting limitations in RecordingPainter API The current set of stacking context commands do not encode the information needed to correctly paint the stacking context, instead, they're based on the limitations of the current CPU renderer. Stacking contexts should be able to be transformed by an arbitrary 3D transformation matrix, not just scaled from a source to a destination rect. The `_with_mask()` stacking context also should not be separate from the regular stacking context. ```c++ push_stacking_context( bool semitransparent_or_has_non_identity_transform, float opacity, Gfx::FloatRect const& source_rect, Gfx::FloatRect const& transformed_destination_rect, Gfx::IntPoint const& painter_location); pop_stacking_context( bool semitransparent_or_has_non_identity_transform, Gfx::Painter::ScalingMode scaling_mode); push_stacking_context_with_mask( Gfx::IntRect const& paint_rect); pop_stacking_context_with_mask( Gfx::IntRect const& paint_rect, RefPtr<Gfx::Bitmap> const& mask_bitmap, Gfx::Bitmap::MaskKind mask_kind, float opacity); ``` This patch replaces this APIs with just: ```c++ push_stacking_context( float opacity, bool is_fixed_position, Gfx::IntRect const& source_paintable_rect, Gfx::IntPoint post_transform_translation, CSS::ImageRendering image_rendering, StackingContextTransform transform, Optional<StackingContextMask> mask); pop_stacking_context() ``` And moves the implementation details into the executor, this should allow future backends to implement stacking contexts without these limitations.
2023-11-18 14:23:59 +00:00
auto* m = matrix.elements();
m[0][3] *= scale;
m[1][3] *= scale;
m[2][3] *= scale;
return matrix;
}
LibWeb: Implement position:fixed painting at the stacking context level This makes everything within the stacking context stick show up in the correct position.
2021-10-14 23:49:15 +02:00
LibWeb: Don't encode painting limitations in RecordingPainter API The current set of stacking context commands do not encode the information needed to correctly paint the stacking context, instead, they're based on the limitations of the current CPU renderer. Stacking contexts should be able to be transformed by an arbitrary 3D transformation matrix, not just scaled from a source to a destination rect. The `_with_mask()` stacking context also should not be separate from the regular stacking context. ```c++ push_stacking_context( bool semitransparent_or_has_non_identity_transform, float opacity, Gfx::FloatRect const& source_rect, Gfx::FloatRect const& transformed_destination_rect, Gfx::IntPoint const& painter_location); pop_stacking_context( bool semitransparent_or_has_non_identity_transform, Gfx::Painter::ScalingMode scaling_mode); push_stacking_context_with_mask( Gfx::IntRect const& paint_rect); pop_stacking_context_with_mask( Gfx::IntRect const& paint_rect, RefPtr<Gfx::Bitmap> const& mask_bitmap, Gfx::Bitmap::MaskKind mask_kind, float opacity); ``` This patch replaces this APIs with just: ```c++ push_stacking_context( float opacity, bool is_fixed_position, Gfx::IntRect const& source_paintable_rect, Gfx::IntPoint post_transform_translation, CSS::ImageRendering image_rendering, StackingContextTransform transform, Optional<StackingContextMask> mask); pop_stacking_context() ``` And moves the implementation details into the executor, this should allow future backends to implement stacking contexts without these limitations.
2023-11-18 14:23:59 +00:00
void StackingContext::paint(PaintContext& context) const
{
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
auto opacity = paintable_box().computed_values().opacity();
LibWeb: Make computed opacity always available No need to store opacity as Optional<float> as there's always a value (and the default initial value is 1.)
2021-10-19 15:27:40 +02:00
if (opacity == 0.0f)
LibWeb: Draw elements with opacity in a separate stacking context
2021-07-23 13:19:16 +03:00
return;
LibWeb: Rename RecordingPainter to DisplayListRecorder Use more widely recognized name among browser engine developers.
2024-06-23 18:40:10 +02:00
DisplayListRecorderStateSaver saver(context.display_list_recorder());
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
LibWeb: Don't encode painting limitations in RecordingPainter API The current set of stacking context commands do not encode the information needed to correctly paint the stacking context, instead, they're based on the limitations of the current CPU renderer. Stacking contexts should be able to be transformed by an arbitrary 3D transformation matrix, not just scaled from a source to a destination rect. The `_with_mask()` stacking context also should not be separate from the regular stacking context. ```c++ push_stacking_context( bool semitransparent_or_has_non_identity_transform, float opacity, Gfx::FloatRect const& source_rect, Gfx::FloatRect const& transformed_destination_rect, Gfx::IntPoint const& painter_location); pop_stacking_context( bool semitransparent_or_has_non_identity_transform, Gfx::Painter::ScalingMode scaling_mode); push_stacking_context_with_mask( Gfx::IntRect const& paint_rect); pop_stacking_context_with_mask( Gfx::IntRect const& paint_rect, RefPtr<Gfx::Bitmap> const& mask_bitmap, Gfx::Bitmap::MaskKind mask_kind, float opacity); ``` This patch replaces this APIs with just: ```c++ push_stacking_context( float opacity, bool is_fixed_position, Gfx::IntRect const& source_paintable_rect, Gfx::IntPoint post_transform_translation, CSS::ImageRendering image_rendering, StackingContextTransform transform, Optional<StackingContextMask> mask); pop_stacking_context() ``` And moves the implementation details into the executor, this should allow future backends to implement stacking contexts without these limitations.
2023-11-18 14:23:59 +00:00
auto to_device_pixels_scale = float(context.device_pixels_per_css_pixel());
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
auto source_paintable_rect = context.enclosing_device_rect(paintable_box().absolute_paint_rect()).to_type<int>();
LibWeb: Allow inline nodes to establish a stacking context With this change, a stacking context can be established by any paintable, including inline paintables. The stacking context traversal is updated to remove the assumption that the stacking context root is paintable box.
2024-01-03 02:40:31 +01:00
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
auto transform_matrix = paintable_box().transform();
auto transform_origin = paintable_box().transform_origin().to_type<float>();
LibWeb: Resolve CSS transform properties during layout commit Now, instead of resolving "transform" and "transform-origin" during the construction of the stacking context tree, we do so during the layout commit. This is part of a refactoring effort to make the paintable tree independent from the layout tree.
2024-01-16 19:54:05 +01:00
LibWeb/CSS: Implement mix-blend-mode This adds support for the `mix-blend-mode` CSS property.
2025-01-22 09:50:49 +01:00
Gfx::CompositingAndBlendingOperator compositing_and_blending_operator;
switch (paintable_box().computed_values().mix_blend_mode()) {
#undef __ENUMERATE
#define __ENUMERATE(mix_blend_mode) \
case CSS::MixBlendMode::mix_blend_mode: \
compositing_and_blending_operator = Gfx::CompositingAndBlendingOperator::mix_blend_mode; \
break;
ENUMERATE_MIX_BLEND_MODES(__ENUMERATE)
#undef __ENUMERATE
}
LibWeb: Rename RecordingPainter to DisplayListRecorder Use more widely recognized name among browser engine developers.
2024-06-23 18:40:10 +02:00
DisplayListRecorder::PushStackingContextParams push_stacking_context_params {
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
.opacity = opacity,
LibWeb/CSS: Implement mix-blend-mode This adds support for the `mix-blend-mode` CSS property.
2025-01-22 09:50:49 +01:00
.compositing_and_blending_operator = compositing_and_blending_operator,
.isolate = paintable_box().computed_values().isolation() == CSS::Isolation::Isolate,
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
.is_fixed_position = paintable_box().is_fixed_position(),
LibWeb: Allow inline nodes to establish a stacking context With this change, a stacking context can be established by any paintable, including inline paintables. The stacking context traversal is updated to remove the assumption that the stacking context root is paintable box.
2024-01-03 02:40:31 +01:00
.source_paintable_rect = source_paintable_rect,
LibWeb: Don't encode painting limitations in RecordingPainter API The current set of stacking context commands do not encode the information needed to correctly paint the stacking context, instead, they're based on the limitations of the current CPU renderer. Stacking contexts should be able to be transformed by an arbitrary 3D transformation matrix, not just scaled from a source to a destination rect. The `_with_mask()` stacking context also should not be separate from the regular stacking context. ```c++ push_stacking_context( bool semitransparent_or_has_non_identity_transform, float opacity, Gfx::FloatRect const& source_rect, Gfx::FloatRect const& transformed_destination_rect, Gfx::IntPoint const& painter_location); pop_stacking_context( bool semitransparent_or_has_non_identity_transform, Gfx::Painter::ScalingMode scaling_mode); push_stacking_context_with_mask( Gfx::IntRect const& paint_rect); pop_stacking_context_with_mask( Gfx::IntRect const& paint_rect, RefPtr<Gfx::Bitmap> const& mask_bitmap, Gfx::Bitmap::MaskKind mask_kind, float opacity); ``` This patch replaces this APIs with just: ```c++ push_stacking_context( float opacity, bool is_fixed_position, Gfx::IntRect const& source_paintable_rect, Gfx::IntPoint post_transform_translation, CSS::ImageRendering image_rendering, StackingContextTransform transform, Optional<StackingContextMask> mask); pop_stacking_context() ``` And moves the implementation details into the executor, this should allow future backends to implement stacking contexts without these limitations.
2023-11-18 14:23:59 +00:00
.transform = {
LibWeb: Resolve CSS transform properties during layout commit Now, instead of resolving "transform" and "transform-origin" during the construction of the stacking context tree, we do so during the layout commit. This is part of a refactoring effort to make the paintable tree independent from the layout tree.
2024-01-16 19:54:05 +01:00
.origin = transform_origin.scaled(to_device_pixels_scale),
.matrix = matrix_with_scaled_translation(transform_matrix, to_device_pixels_scale),
LibWeb: Don't encode painting limitations in RecordingPainter API The current set of stacking context commands do not encode the information needed to correctly paint the stacking context, instead, they're based on the limitations of the current CPU renderer. Stacking contexts should be able to be transformed by an arbitrary 3D transformation matrix, not just scaled from a source to a destination rect. The `_with_mask()` stacking context also should not be separate from the regular stacking context. ```c++ push_stacking_context( bool semitransparent_or_has_non_identity_transform, float opacity, Gfx::FloatRect const& source_rect, Gfx::FloatRect const& transformed_destination_rect, Gfx::IntPoint const& painter_location); pop_stacking_context( bool semitransparent_or_has_non_identity_transform, Gfx::Painter::ScalingMode scaling_mode); push_stacking_context_with_mask( Gfx::IntRect const& paint_rect); pop_stacking_context_with_mask( Gfx::IntRect const& paint_rect, RefPtr<Gfx::Bitmap> const& mask_bitmap, Gfx::Bitmap::MaskKind mask_kind, float opacity); ``` This patch replaces this APIs with just: ```c++ push_stacking_context( float opacity, bool is_fixed_position, Gfx::IntRect const& source_paintable_rect, Gfx::IntPoint post_transform_translation, CSS::ImageRendering image_rendering, StackingContextTransform transform, Optional<StackingContextMask> mask); pop_stacking_context() ``` And moves the implementation details into the executor, this should allow future backends to implement stacking contexts without these limitations.
2023-11-18 14:23:59 +00:00
},
LibWeb: Introduce RecordingPainter to serialize painting commands This modification introduces a new layer to the painting process. The stacking context traversal no longer immediately calls the Gfx::Painter methods. Instead, it writes serialized painting commands into newly introduced RecordingPainter. Created list of commands is executed later to produce resulting bitmap. Producing painting command list will make it easier to add new optimizations: - It's simpler to check if the painting result is not visible in the viewport at the command level rather than during stacking context traversal. - Run painting in a separate thread. The painting thread can process serialized painting commands, while the main thread can work on the next paintable tree and safely invalidate the previous one. - As we consider GPU-accelerated painting support, it would be easier to back each painting command rather than constructing an alternative for the entire Gfx::Painter API.
2023-10-15 04:27:48 +02:00
};
LibWeb: Sample the destination when painting element opacity/transform This now copies the area under the destination to a new bitmap, that is then scaled to the size of the source. The element is then painted into that bitmap, which is then scaled and painted back to the destination. This is done as many effects such as shadows, border radii, filters, etc require being able to read pixels from the painter. This does work (and is not that noticeable in many cases), but it does mean there may be a few scaling artifacts in the background around transformed elements. Though that was already the case before anyway for the elements (since it is just a bitmap scale). What we really want is to (where possible) just scale the paintable and its descendants, then paint things normally, which would give much nicer results (but is much more tricky to achieve). This also now makes it so only a bitmap of the size of the paintable is copied/created, rather than the whole page.
2022-09-25 15:24:21 +01:00
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
auto const& computed_values = paintable_box().computed_values();
LibWeb: Do not allocate mask bitmap for CSS "clip-path" property Instead, it could be applied directly as a clip path in Skia painter. As a side bonus, we get rid of some DeprecatedPath and AntiAliasingPainter usage.
2024-08-20 17:27:08 +02:00
if (auto clip_path = computed_values.clip_path(); clip_path.has_value() && clip_path->is_basic_shape()) {
auto const& masking_area = paintable_box().get_masking_area();
auto const& basic_shape = computed_values.clip_path()->basic_shape();
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
auto path = basic_shape.to_path(*masking_area, paintable_box().layout_node());
LibWeb: Do not allocate mask bitmap for CSS "clip-path" property Instead, it could be applied directly as a clip path in Skia painter. As a side bonus, we get rid of some DeprecatedPath and AntiAliasingPainter usage.
2024-08-20 17:27:08 +02:00
auto device_pixel_scale = context.device_pixels_per_css_pixel();
push_stacking_context_params.clip_path = path.copy_transformed(Gfx::AffineTransform {}.set_scale(device_pixel_scale, device_pixel_scale).set_translation(source_paintable_rect.location().to_type<float>()));
}
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
auto has_css_transform = paintable_box().has_css_transform();
LibWeb: Rename RecordingPainter to DisplayListRecorder Use more widely recognized name among browser engine developers.
2024-06-23 18:40:10 +02:00
context.display_list_recorder().save();
LibWeb: Fix overflow clip when "complicated" CSS transform is used Overflow clipping is currently implemented as: 1. Create clip frame for each box with hidden overflow 2. Calculate clip rect for each clip frame by intersecting padding boxes of all boxes with hidden overflow in containing block chain 3. Assign enclosing clip frame (closest clip frame in containing block chain) to each PaintableBox 4. Apply clip rect of enclosing clip frame in Paintable::before_paint() It breaks when any CSS transform other than simple translation is lying between box with hidden overflow and a clipped box, because clip rectangle will be applied when transform has already changed. The fix is implemented by relying on the following rule: "For elements whose layout is governed by the CSS box model, any value other than none for the transform also causes the element to establish a containing block for all descendants." It means everything nested into a stacking context with CSS transform can't escape its clip, so it's safe to apply its clip for all children.
2024-07-31 22:26:43 +03:00
if (has_css_transform) {
paintable_box().apply_clip_overflow_rect(context, PaintPhase::Foreground);
}
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
if (paintable_box().scroll_frame_id().has_value()) {
LibWeb: Don't produce save & restore commands for scroll frame id change This allows to substantially decrease display list length and save/restore churn during painting. Display list size comparison: | | Before | After | | ------------- | ------ | ------ | | basecamp.com | 19066 | 12248 | | ladybird.org | 8878 | 2220 | | react.dev | 39074 | 24382 |
2024-10-11 15:18:39 +02:00
context.display_list_recorder().push_scroll_frame_id(*paintable_box().scroll_frame_id());
}
LibWeb: Rename RecordingPainter to DisplayListRecorder Use more widely recognized name among browser engine developers.
2024-06-23 18:40:10 +02:00
context.display_list_recorder().push_stacking_context(push_stacking_context_params);
LibWeb: Use separate restore() for each ApplyFilters display list item ApplyFilter internally calls canvas.saveLayer() which requires a matching canvas.restore() to be called. Fixes painting on https://supabase.com/ regressed by 8562b0e33bd057d9aa5be1b6ce66db039bc99576
2024-12-01 15:26:20 +01:00
auto const& filter = computed_values.filter();
LibWeb+LibGfx: Refactor CSS filters into LibGfx CSS filters work similarly to canvas filters, so it makes sense to have Gfx::Filter that can be used by both libraries in an analogous way as Gfx::Color.
2024-12-18 11:34:25 +01:00
if (!filter.is_empty()) {
LibWeb: Use separate restore() for each ApplyFilters display list item ApplyFilter internally calls canvas.saveLayer() which requires a matching canvas.restore() to be called. Fixes painting on https://supabase.com/ regressed by 8562b0e33bd057d9aa5be1b6ce66db039bc99576
2024-12-01 15:26:20 +01:00
context.display_list_recorder().apply_filters(paintable_box().computed_values().filter());
}
LibWeb: Don't allow SVG boxes to create a stacking context Prior to this change, SVGs were following the CSS painting order, which means SVG boxes could have established stacking context and be sorted by z-index. There is a section in the spec that defines what kind of SVG boxes should create a stacking context https://www.w3.org/TR/SVG2/render.html#EstablishingStackingContex Although this spec is marked as a draft and rendering order described in this spec does not match what other engines do. This spec issue comment has a good summary of what other engines actually do regarding painting order https://github.com/w3c/svgwg/issues/264#issuecomment-246432360 "as long as you're relying solely on the default z-index (which SVG1 does, by definition), nothing ever changes order when you apply opacity/filter/etc". This change aligns our implementation with other engines by forbidding SVGs to create a formatting context and painting them in order they are defined in tree tree.
2024-10-09 02:57:57 +02:00
LibWeb: Implement `mask-image` CSS property support Implemented by reusing AddMask display list item that was initially added for `background-clip` property. Progress on flashlight effect on https://null.com/games/athena-crisis
2024-11-16 03:25:48 +03:00
if (auto mask_image = computed_values.mask_image()) {
auto mask_display_list = DisplayList::create();
DisplayListRecorder display_list_recorder(*mask_display_list);
auto mask_painting_context = context.clone(display_list_recorder);
auto mask_rect_in_device_pixels = context.enclosing_device_rect(paintable_box().absolute_padding_box_rect());
mask_image->paint(mask_painting_context, { {}, mask_rect_in_device_pixels.size() }, CSS::ImageRendering::Auto);
context.display_list_recorder().add_mask(mask_display_list, mask_rect_in_device_pixels.to_type<int>());
}
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
if (auto masking_area = paintable_box().get_masking_area(); masking_area.has_value()) {
if (masking_area->is_empty())
return;
auto mask_bitmap = paintable_box().calculate_mask(context, *masking_area);
if (mask_bitmap) {
auto masking_area_rect = context.enclosing_device_rect(*masking_area).to_type<int>();
context.display_list_recorder().apply_mask_bitmap(masking_area_rect.location(), mask_bitmap.release_nonnull(), *paintable_box().get_mask_type());
LibWeb: Don't allow SVG boxes to create a stacking context Prior to this change, SVGs were following the CSS painting order, which means SVG boxes could have established stacking context and be sorted by z-index. There is a section in the spec that defines what kind of SVG boxes should create a stacking context https://www.w3.org/TR/SVG2/render.html#EstablishingStackingContex Although this spec is marked as a draft and rendering order described in this spec does not match what other engines do. This spec issue comment has a good summary of what other engines actually do regarding painting order https://github.com/w3c/svgwg/issues/264#issuecomment-246432360 "as long as you're relying solely on the default z-index (which SVG1 does, by definition), nothing ever changes order when you apply opacity/filter/etc". This change aligns our implementation with other engines by forbidding SVGs to create a formatting context and painting them in order they are defined in tree tree.
2024-10-09 02:57:57 +02:00
}
}
LibWeb: Fix CSS filters painting restore() corresponding to ApplyFilters should be called after stacking context content is painted, not before. Fixes regression introduced in c94b4316e7a2f3d245f9b48f77a7f9f76785218a
2024-12-01 20:45:47 +01:00
paint_internal(context);
LibWeb+LibGfx: Refactor CSS filters into LibGfx CSS filters work similarly to canvas filters, so it makes sense to have Gfx::Filter that can be used by both libraries in an analogous way as Gfx::Color.
2024-12-18 11:34:25 +01:00
if (!filter.is_empty()) {
LibWeb: Use separate restore() for each ApplyFilters display list item ApplyFilter internally calls canvas.saveLayer() which requires a matching canvas.restore() to be called. Fixes painting on https://supabase.com/ regressed by 8562b0e33bd057d9aa5be1b6ce66db039bc99576
2024-12-01 15:26:20 +01:00
context.display_list_recorder().restore();
}
LibWeb: Rename RecordingPainter to DisplayListRecorder Use more widely recognized name among browser engine developers.
2024-06-23 18:40:10 +02:00
context.display_list_recorder().pop_stacking_context();
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
if (paintable_box().scroll_frame_id().has_value()) {
LibWeb: Don't produce save & restore commands for scroll frame id change This allows to substantially decrease display list length and save/restore churn during painting. Display list size comparison: | | Before | After | | ------------- | ------ | ------ | | basecamp.com | 19066 | 12248 | | ladybird.org | 8878 | 2220 | | react.dev | 39074 | 24382 |
2024-10-11 15:18:39 +02:00
context.display_list_recorder().pop_scroll_frame_id();
}
LibWeb: Fix overflow clip when "complicated" CSS transform is used Overflow clipping is currently implemented as: 1. Create clip frame for each box with hidden overflow 2. Calculate clip rect for each clip frame by intersecting padding boxes of all boxes with hidden overflow in containing block chain 3. Assign enclosing clip frame (closest clip frame in containing block chain) to each PaintableBox 4. Apply clip rect of enclosing clip frame in Paintable::before_paint() It breaks when any CSS transform other than simple translation is lying between box with hidden overflow and a clipped box, because clip rectangle will be applied when transform has already changed. The fix is implemented by relying on the following rule: "For elements whose layout is governed by the CSS box model, any value other than none for the transform also causes the element to establish a containing block for all descendants." It means everything nested into a stacking context with CSS transform can't escape its clip, so it's safe to apply its clip for all children.
2024-07-31 22:26:43 +03:00
if (has_css_transform)
paintable_box().clear_clip_overflow_rect(context, PaintPhase::Foreground);
LibWeb: Rename RecordingPainter to DisplayListRecorder Use more widely recognized name among browser engine developers.
2024-06-23 18:40:10 +02:00
context.display_list_recorder().restore();
LibWeb: Draw elements with opacity in a separate stacking context
2021-07-23 13:19:16 +03:00
}
LibWeb: Change StackingContext::hit_test() to accept callback This change modifies hit_test() to no longer return the first paintable encountered at a specified position. Instead, this function accepts a callback that is invoked for each paintable located at a position, in hit-testing order. This modification will allow us to reuse this call for `Document.elementsFromPoint()` in upcoming changes.
2024-02-13 21:34:07 +01:00
TraversalDecision StackingContext::hit_test(CSSPixelPoint position, HitTestType type, Function<TraversalDecision(HitTestResult)> const& callback) const
LibWeb: Use the StackingContext tree for hit testing This makes it possible to click links that are above other content due to stacking context order (e.g via CSS z-index.)
2020-07-01 19:02:28 +02:00
{
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
if (!paintable_box().is_visible())
LibWeb: Change StackingContext::hit_test() to accept callback This change modifies hit_test() to no longer return the first paintable encountered at a specified position. Instead, this function accepts a callback that is invoked for each paintable located at a position, in hit-testing order. This modification will allow us to reuse this call for `Document.elementsFromPoint()` in upcoming changes.
2024-02-13 21:34:07 +01:00
return TraversalDecision::Continue;
LibWeb: Make hit testing respect hidden overflow
2022-07-03 18:34:51 -03:00
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
CSSPixelPoint transform_origin = paintable_box().transform_origin();
LibWeb+WebContent+headless-browser: Use CSSPixels for PageClient events ...and also for hit testing, which is involved in most of them. Much of this is temporary conversions and other awkwardness, which should resolve itself as the rest of LibWeb is converted to these new types. Hopefully. :thousandyakstare:
2022-11-02 17:35:53 +00:00
// NOTE: This CSSPixels -> Float -> CSSPixels conversion is because we can't AffineTransform::map() a CSSPixelPoint.
LibWeb: Simplify hit testing coordinate calculations There are many simpler APIs that we can use here. No functional changes.
2025-01-20 14:34:40 +01:00
auto offset_position = position.translated(-transform_origin).to_type<float>();
LibWeb+WebContent+headless-browser: Use CSSPixels for PageClient events ...and also for hit testing, which is involved in most of them. Much of this is temporary conversions and other awkwardness, which should resolve itself as the rest of LibWeb is converted to these new types. Hopefully. :thousandyakstare:
2022-11-02 17:35:53 +00:00
auto transformed_position = affine_transform_matrix().inverse().value_or({}).map(offset_position).to_type<CSSPixels>() + transform_origin;
LibWeb: Update hit_test for CSS Transforms This now also takes a FloatPoint instead of an IntPoint to avoid excessive rounding when multiple transforms apply on top of each other.
2022-03-18 01:32:50 +01:00
LibWeb: Implement hit testing a bit closer to spec We now perform hit testing in reverse paint order as described in CSS2's section about the z-index property.
2022-03-04 15:02:16 +01:00
// NOTE: Hit testing basically happens in reverse painting order.
// https://www.w3.org/TR/CSS22/visuren.html#z-index
// 7. the child stacking contexts with positive stack levels (least positive first).
LibWeb: Don't hit test all child stacking contexts twice We're supposed to hit test positive z-index stacking contexts first, and negative z-index stacking contexts later. Instead, we were hit testing all stacking contexts both times. This made hit testing unbearably slow on some websites. While we're here, also add an extra comment about why stacking contexts are traversed in reverse order. It tripped me up while looking at this, so I'm sure it could trip someone else up too. Regressed in 44057c94821ea5dbfa2747de7cd4053fd5fe0742.
2022-10-07 11:51:56 +02:00
// NOTE: Hit testing follows reverse painting order, that's why the conditions here are reversed.
LibWeb: Implement hit testing a bit closer to spec We now perform hit testing in reverse paint order as described in CSS2's section about the z-index property.
2022-03-04 15:02:16 +01:00
for (ssize_t i = m_children.size() - 1; i >= 0; --i) {
auto const& child = *m_children[i];
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
if (child.paintable_box().computed_values().z_index().value_or(0) <= 0)
LibWeb: Don't hit test all child stacking contexts twice We're supposed to hit test positive z-index stacking contexts first, and negative z-index stacking contexts later. Instead, we were hit testing all stacking contexts both times. This made hit testing unbearably slow on some websites. While we're here, also add an extra comment about why stacking contexts are traversed in reverse order. It tripped me up while looking at this, so I'm sure it could trip someone else up too. Regressed in 44057c94821ea5dbfa2747de7cd4053fd5fe0742.
2022-10-07 11:51:56 +02:00
break;
LibWeb: Change StackingContext::hit_test() to accept callback This change modifies hit_test() to no longer return the first paintable encountered at a specified position. Instead, this function accepts a callback that is invoked for each paintable located at a position, in hit-testing order. This modification will allow us to reuse this call for `Document.elementsFromPoint()` in upcoming changes.
2024-02-13 21:34:07 +01:00
if (child.hit_test(transformed_position, type, callback) == TraversalDecision::Break)
return TraversalDecision::Break;
LibWeb: Implement hit testing a bit closer to spec We now perform hit testing in reverse paint order as described in CSS2's section about the z-index property.
2022-03-04 15:02:16 +01:00
}
// 6. the child stacking contexts with stack level 0 and the positioned descendants with stack level 0.
LibWeb: Don't ignore non-positioned stacking contexts on step 8 of paint ...traversal. We've already fixed step 3 and 9 to not filter out non-positioned stacking contexts, because modern CSS has more ways to create stacking context besides being positioned with z-index (like by using "transform", "filter" or "clip-path" properties). See following spec issue for more details https://github.com/w3c/csswg-drafts/issues/2717 Visual improvement on https://basecamp.com/
2024-10-09 03:49:49 +02:00
for (auto const& paintable : m_positioned_descendants_and_stacking_contexts_with_stack_level_0.in_reverse()) {
LibWeb: Fix some GCVerifier warnings
2024-04-05 13:47:48 -07:00
if (paintable->stacking_context()) {
if (paintable->stacking_context()->hit_test(transformed_position, type, callback) == TraversalDecision::Break)
LibWeb: Reduce paintable tree traversals during hit-testing By storing a list of positioned and floating descendants within the stacking context tree node, we can eliminate the need for costly paintable tree traversals during hit-testing. This optimization results in hit-testing being 2 to 2.5 times faster on https://ziglang.org/documentation/master/
2024-03-01 11:54:44 +01:00
return TraversalDecision::Break;
} else {
LibWeb: Fix some GCVerifier warnings
2024-04-05 13:47:48 -07:00
if (paintable->hit_test(transformed_position, type, callback) == TraversalDecision::Break)
LibWeb: Make SC hit testing more closely follow reverse paint order Previously, we would hit test positioned elements, then stacking contexts with z-index 0, as two seperate steps. This did not really follow the reverse paint order, where positioned elements and stacking contexts with z-index 0 are painted during the same tree transversal. This commit updates for_each_in_subtree_of_type_within_same_stacking_context_in_reverse() to return the stacking contexts it comes across too, but not recurse into them. This more closely follows the paint order. This fixes examples such as: <div id="a" style="width: 10px; height: 10px"> <div id="b" style="position: absolute; width: 10px; height: 10px"> <div style="position: absolute; width: 10px; height: 10px; z-index: 0" > <div id="c" style="width: 100%; height: 100%; background-color:red;" onclick="alert('You Win!')"> </div> </div> </div> </div> Where previously the onclick on #c would never fire as hit testing always stopped at #b. This is reduced from Google Street View, which becomes interactable after this commit.
2023-04-09 11:21:00 +01:00
return TraversalDecision::Break;
LibWeb: Make hit testing traverse positioned descendants in right order We were doing a forward traversal in hit testing which led to sometimes incorrect results when multiple boxes were occupying the same X and Y coordinate.
2022-11-03 19:08:07 +01:00
}
LibWeb: Reduce paintable tree traversals during hit-testing By storing a list of positioned and floating descendants within the stacking context tree node, we can eliminate the need for costly paintable tree traversals during hit-testing. This optimization results in hit-testing being 2 to 2.5 times faster on https://ziglang.org/documentation/master/
2024-03-01 11:54:44 +01:00
}
LibWeb: Implement hit testing a bit closer to spec We now perform hit testing in reverse paint order as described in CSS2's section about the z-index property.
2022-03-04 15:02:16 +01:00
// 5. the in-flow, inline-level, non-positioned descendants, including inline tables and inline blocks.
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
if (paintable_box().layout_node().children_are_inline() && is<Layout::BlockContainer>(paintable_box().layout_node())) {
for (auto const* child = paintable_box().last_child(); child; child = child->previous_sibling()) {
if (child->is_inline() && !child->is_absolutely_positioned() && !child->has_stacking_context()) {
LibWeb: Avoid infinite recursion when hit testing SVGs Previously, step 5 of the stacking context hit testing would just call `hit_test()` on the stacking context's paintable box. Which (at least for SVGs) is just indirect infinite recursion (it'll end up right back where it started after going through a few functions). This now explicitly hit tests the descendants, which seems more correct, and avoids the crash for SVGs, but nothing really seems to depend on this step. Another solution (which I've done for a while working on SVGs) is just to delete step 5 entirely, and nothing seems to break. Fixes #22305
2024-02-17 18:53:32 +00:00
if (child->hit_test(transformed_position, type, callback) == TraversalDecision::Break)
return TraversalDecision::Break;
}
}
LibWeb: Use the StackingContext tree for hit testing This makes it possible to click links that are above other content due to stacking context order (e.g via CSS z-index.)
2020-07-01 19:02:28 +02:00
}
LibWeb: Implement hit testing a bit closer to spec We now perform hit testing in reverse paint order as described in CSS2's section about the z-index property.
2022-03-04 15:02:16 +01:00
// 4. the non-positioned floats.
LibWeb: Reduce paintable tree traversals during hit-testing By storing a list of positioned and floating descendants within the stacking context tree node, we can eliminate the need for costly paintable tree traversals during hit-testing. This optimization results in hit-testing being 2 to 2.5 times faster on https://ziglang.org/documentation/master/
2024-03-01 11:54:44 +01:00
for (auto const& paintable : m_non_positioned_floating_descendants.in_reverse()) {
LibWeb: Fix some GCVerifier warnings
2024-04-05 13:47:48 -07:00
if (paintable->hit_test(transformed_position, type, callback) == TraversalDecision::Break)
LibWeb: Reduce paintable tree traversals during hit-testing By storing a list of positioned and floating descendants within the stacking context tree node, we can eliminate the need for costly paintable tree traversals during hit-testing. This optimization results in hit-testing being 2 to 2.5 times faster on https://ziglang.org/documentation/master/
2024-03-01 11:54:44 +01:00
return TraversalDecision::Break;
}
LibWeb: Implement hit testing a bit closer to spec We now perform hit testing in reverse paint order as described in CSS2's section about the z-index property.
2022-03-04 15:02:16 +01:00
// 3. the in-flow, non-inline-level, non-positioned descendants.
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
if (!paintable_box().layout_node().children_are_inline()) {
for (auto const* child = paintable_box().last_child(); child; child = child->previous_sibling()) {
LibWeb: Change StackingContext::hit_test() to accept callback This change modifies hit_test() to no longer return the first paintable encountered at a specified position. Instead, this function accepts a callback that is invoked for each paintable located at a position, in hit-testing order. This modification will allow us to reuse this call for `Document.elementsFromPoint()` in upcoming changes.
2024-02-13 21:34:07 +01:00
if (!child->is_paintable_box())
continue;
AK+Everywhere: Rename `verify_cast` to `as` Follow-up to fc20e61e7249006247b43f84a3189d5a37fa103e.
2025-01-21 09:12:05 -05:00
auto const& paintable_box = as<PaintableBox>(*child);
LibWeb: Change StackingContext::hit_test() to accept callback This change modifies hit_test() to no longer return the first paintable encountered at a specified position. Instead, this function accepts a callback that is invoked for each paintable located at a position, in hit-testing order. This modification will allow us to reuse this call for `Document.elementsFromPoint()` in upcoming changes.
2024-02-13 21:34:07 +01:00
if (!paintable_box.is_absolutely_positioned() && !paintable_box.is_floating() && !paintable_box.stacking_context()) {
if (paintable_box.hit_test(transformed_position, type, callback) == TraversalDecision::Break)
LibWeb: Make hit testing traverse positioned descendants in right order We were doing a forward traversal in hit testing which led to sometimes incorrect results when multiple boxes were occupying the same X and Y coordinate.
2022-11-03 19:08:07 +01:00
return TraversalDecision::Break;
LibWeb: Implement hit testing a bit closer to spec We now perform hit testing in reverse paint order as described in CSS2's section about the z-index property.
2022-03-04 15:02:16 +01:00
}
LibWeb: Change StackingContext::hit_test() to accept callback This change modifies hit_test() to no longer return the first paintable encountered at a specified position. Instead, this function accepts a callback that is invoked for each paintable located at a position, in hit-testing order. This modification will allow us to reuse this call for `Document.elementsFromPoint()` in upcoming changes.
2024-02-13 21:34:07 +01:00
}
LibWeb: Implement hit testing a bit closer to spec We now perform hit testing in reverse paint order as described in CSS2's section about the z-index property.
2022-03-04 15:02:16 +01:00
}
LibWeb: Don't hit test a stacked child if it is behind its parent When hit testing a stacked context, skip hit testing children if the child's z-index is less than the parent's. The children are already sorted by z-index, but also need to consider the parent.
2021-03-31 10:26:11 -04:00
LibWeb: Implement hit testing a bit closer to spec We now perform hit testing in reverse paint order as described in CSS2's section about the z-index property.
2022-03-04 15:02:16 +01:00
// 2. the child stacking contexts with negative stack levels (most negative first).
LibWeb: Don't hit test all child stacking contexts twice We're supposed to hit test positive z-index stacking contexts first, and negative z-index stacking contexts later. Instead, we were hit testing all stacking contexts both times. This made hit testing unbearably slow on some websites. While we're here, also add an extra comment about why stacking contexts are traversed in reverse order. It tripped me up while looking at this, so I'm sure it could trip someone else up too. Regressed in 44057c94821ea5dbfa2747de7cd4053fd5fe0742.
2022-10-07 11:51:56 +02:00
// NOTE: Hit testing follows reverse painting order, that's why the conditions here are reversed.
LibWeb: Implement hit testing a bit closer to spec We now perform hit testing in reverse paint order as described in CSS2's section about the z-index property.
2022-03-04 15:02:16 +01:00
for (ssize_t i = m_children.size() - 1; i >= 0; --i) {
auto const& child = *m_children[i];
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
if (child.paintable_box().computed_values().z_index().value_or(0) >= 0)
LibWeb: Don't hit test all child stacking contexts twice We're supposed to hit test positive z-index stacking contexts first, and negative z-index stacking contexts later. Instead, we were hit testing all stacking contexts both times. This made hit testing unbearably slow on some websites. While we're here, also add an extra comment about why stacking contexts are traversed in reverse order. It tripped me up while looking at this, so I'm sure it could trip someone else up too. Regressed in 44057c94821ea5dbfa2747de7cd4053fd5fe0742.
2022-10-07 11:51:56 +02:00
break;
LibWeb: Change StackingContext::hit_test() to accept callback This change modifies hit_test() to no longer return the first paintable encountered at a specified position. Instead, this function accepts a callback that is invoked for each paintable located at a position, in hit-testing order. This modification will allow us to reuse this call for `Document.elementsFromPoint()` in upcoming changes.
2024-02-13 21:34:07 +01:00
if (child.hit_test(transformed_position, type, callback) == TraversalDecision::Break)
return TraversalDecision::Break;
LibWeb: Implement hit testing a bit closer to spec We now perform hit testing in reverse paint order as described in CSS2's section about the z-index property.
2022-03-04 15:02:16 +01:00
}
LibWeb: Don't hit test a stacked child if it is behind its parent When hit testing a stacked context, skip hit testing children if the child's z-index is less than the parent's. The children are already sorted by z-index, but also need to consider the parent.
2021-03-31 10:26:11 -04:00
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
CSSPixelPoint enclosing_scroll_offset = paintable_box().cumulative_offset_of_enclosing_scroll_frame();
LibWeb: Adjust stacking context position by scroll offset in hit-testing Fixes a bug when stacking contexts nested inside scrollable box are treated as fixed positioned during hit-testing.
2024-08-07 16:24:27 +03:00
LibWeb: Honor `pointer-events` for PaintableBox in own stacking context If a block element with its own stacking context has `pointer-events: none` set, it should be ignored as far as hit-testing goes. Fixes #3357.
2025-01-25 22:41:21 +01:00
auto position_adjusted_by_scroll_offset = transformed_position.translated(-enclosing_scroll_offset);
LibWeb: Adjust stacking context position by scroll offset in hit-testing Fixes a bug when stacking contexts nested inside scrollable box are treated as fixed positioned during hit-testing.
2024-08-07 16:24:27 +03:00
LibWeb: Implement hit testing a bit closer to spec We now perform hit testing in reverse paint order as described in CSS2's section about the z-index property.
2022-03-04 15:02:16 +01:00
// 1. the background and borders of the element forming the stacking context.
LibWeb: Honor `pointer-events` for PaintableBox in own stacking context If a block element with its own stacking context has `pointer-events: none` set, it should be ignored as far as hit-testing goes. Fixes #3357.
2025-01-25 22:41:21 +01:00
if (paintable_box().visible_for_hit_testing()
&& paintable_box().absolute_border_box_rect().contains(position_adjusted_by_scroll_offset)) {
if (callback({ const_cast<PaintableBox&>(paintable_box()) }) == TraversalDecision::Break)
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
return TraversalDecision::Break;
LibWeb: Use the StackingContext tree for hit testing This makes it possible to click links that are above other content due to stacking context order (e.g via CSS z-index.)
2020-07-01 19:02:28 +02:00
}
LibWeb: Implement hit testing a bit closer to spec We now perform hit testing in reverse paint order as described in CSS2's section about the z-index property.
2022-03-04 15:02:16 +01:00
LibWeb: Change StackingContext::hit_test() to accept callback This change modifies hit_test() to no longer return the first paintable encountered at a specified position. Instead, this function accepts a callback that is invoked for each paintable located at a position, in hit-testing order. This modification will allow us to reuse this call for `Document.elementsFromPoint()` in upcoming changes.
2024-02-13 21:34:07 +01:00
return TraversalDecision::Continue;
LibWeb: Use the StackingContext tree for hit testing This makes it possible to click links that are above other content due to stacking context order (e.g via CSS z-index.)
2020-07-01 19:02:28 +02:00
}
LibWeb: Respect CSS z-index property while painting To support z-ordering when painting, the layout tree now has a parallel sparse tree of stacking contexts. The rules for which layout boxes establish a stacking context are a bit complex, but the intent is to encapsulate the decision making into establishes_stacking_context(). When we paint, we start from the ICB (LayoutDocument) who always has a StackingContext and then paint the tree of StackingContexts where each node has its children sorted by z-index. This is pretty crude, but gets the basic job done. Note that this does not yet support hit testing; hit testing is still done using a naive treewalk from the root.
2020-06-15 17:29:35 +02:00
void StackingContext::dump(int indent) const
{
LibWeb: Demangle the names returned by Layout::Node::class_name() Note that these are only used in debugging/test output so it's not performance sensitive.
2021-01-01 16:42:44 +01:00
StringBuilder builder;
LibWeb: Respect CSS z-index property while painting To support z-ordering when painting, the layout tree now has a parallel sparse tree of stacking contexts. The rules for which layout boxes establish a stacking context are a bit complex, but the intent is to encapsulate the decision making into establishes_stacking_context(). When we paint, we start from the ICB (LayoutDocument) who always has a StackingContext and then paint the tree of StackingContexts where each node has its children sorted by z-index. This is pretty crude, but gets the basic job done. Note that this does not yet support hit testing; hit testing is still done using a naive treewalk from the root.
2020-06-15 17:29:35 +02:00
for (int i = 0; i < indent; ++i)
LibWeb: Demangle the names returned by Layout::Node::class_name() Note that these are only used in debugging/test output so it's not performance sensitive.
2021-01-01 16:42:44 +01:00
builder.append(' ');
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
CSSPixelRect rect = paintable_box().absolute_rect();
builder.appendff("SC for {} {} [children: {}] (z-index: ", paintable_box().layout_node().debug_description(), rect, m_children.size());
LibWeb: Allow inline nodes to establish a stacking context With this change, a stacking context can be established by any paintable, including inline paintables. The stacking context traversal is updated to remove the assumption that the stacking context root is paintable box.
2024-01-03 02:40:31 +01:00
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
if (paintable_box().computed_values().z_index().has_value())
builder.appendff("{}", paintable_box().computed_values().z_index().value());
LibWeb: Make stacking context tree dumps more readable Include the Layout::Node::debug_description() and the z-index.
2022-03-04 15:03:48 +01:00
else
Everywhere: Add sv suffix to strings relying on StringView(char const*) Each of these strings would previously rely on StringView's char const* constructor overload, which would call __builtin_strlen on the string. Since we now have operator ""sv, we can replace these with much simpler versions. This opens the door to being able to remove StringView(char const*). No functional changes.
2022-07-11 17:32:29 +00:00
builder.append("auto"sv);
LibWeb: Make stacking context tree dumps more readable Include the Layout::Node::debug_description() and the z-index.
2022-03-04 15:03:48 +01:00
builder.append(')');
LibWeb: Implement CSS transforms on stacking contexts Since there is currently no easy way to handle rotations and skews with LibGfx this only implements translation and scaling by first constructing a general 4x4 transformation matrix like outlined in the css-transforms-1 specification. This is then downgraded to a Gfx::AffineTransform in order to transform the destination rectangle used with draw_scaled_bitmap() While rotation would be nice this already looks pretty good :^)
2022-03-18 01:29:20 +01:00
LibWeb: Store calculated transformation matrix on the StackingContext This is mainly so we can easily read that matrix later, but also has the benefit of only calculating the matrix once, instead of every time we paint. :^)
2022-07-19 15:18:20 +01:00
auto affine_transform = affine_transform_matrix();
LibWeb: Implement CSS transforms on stacking contexts Since there is currently no easy way to handle rotations and skews with LibGfx this only implements translation and scaling by first constructing a general 4x4 transformation matrix like outlined in the css-transforms-1 specification. This is then downgraded to a Gfx::AffineTransform in order to transform the destination rectangle used with draw_scaled_bitmap() While rotation would be nice this already looks pretty good :^)
2022-03-18 01:29:20 +01:00
if (!affine_transform.is_identity()) {
builder.appendff(", transform: {}", affine_transform);
}
LibWeb: Demangle the names returned by Layout::Node::class_name() Note that these are only used in debugging/test output so it's not performance sensitive.
2021-01-01 16:42:44 +01:00
dbgln("{}", builder.string_view());
LibWeb: Respect CSS z-index property while painting To support z-ordering when painting, the layout tree now has a parallel sparse tree of stacking contexts. The rules for which layout boxes establish a stacking context are a bit complex, but the intent is to encapsulate the decision making into establishes_stacking_context(). When we paint, we start from the ICB (LayoutDocument) who always has a StackingContext and then paint the tree of StackingContexts where each node has its children sorted by z-index. This is pretty crude, but gets the basic job done. Note that this does not yet support hit testing; hit testing is still done using a naive treewalk from the root.
2020-06-15 17:29:35 +02:00
for (auto& child : m_children)
child->dump(indent + 1);
}
}
Reference in a new issue Copy permalink