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

451 lines
19 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
/*
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
* Copyright (c) 2020-2022, Andreas Kling <kling@serenityos.org>
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
*/
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 <AK/Debug.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
#include <AK/QuickSort.h>
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
#include <AK/StringBuilder.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>
LibWeb: Draw elements with opacity in a separate stacking context
2021-07-23 13:19:16 +03:00
#include <LibGfx/Painter.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/Rect.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: Rename InitialContainingBlockBox => InitialContainingBlock The "Box" suffix added nothing here.
2021-09-08 11:27:46 +02:00
#include <LibWeb/Layout/InitialContainingBlock.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: Move PaintingBox to its own .cpp and .h files
2022-03-10 23:13:37 +01:00
#include <LibWeb/Painting/PaintableBox.h>
LibWeb: Fix broken #include after moving files around
2020-06-18 22:01:05 +02:00
#include <LibWeb/Painting/StackingContext.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: 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
static void paint_node(Layout::Node const& layout_node, PaintContext& context, PaintPhase phase)
{
LibWeb: Port inline elements to the new Paintable system This patch adds InlinePaintable which corresponds to Layout::InlineNode.
2022-03-10 15:38:34 +01:00
if (auto const* paintable = layout_node.paintable())
paintable->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: Move StackingContext and PaintPhase into the Painting namespace
2022-03-10 02:13:28 +01:00
StackingContext::StackingContext(Layout::Box& box, StackingContext* 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_box(box)
, m_parent(parent)
{
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) {
auto a_z_index = a->m_box.computed_values().z_index().value_or(0);
auto b_z_index = b->m_box.computed_values().z_index().value_or(0);
if (a_z_index == b_z_index)
return a->m_box.is_before(b->m_box);
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: 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
{
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
// There are not a fully correct mapping since some stacking context phases are combind.
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
}
void StackingContext::paint_descendants(PaintContext& context, Layout::Node& box, StackingContextPaintPhase phase) const
{
if (auto* paintable = box.paintable())
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 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
box.for_each_child([&](auto& child) {
LibWeb: Don't call establishes_stacking_context() during painting By the time we're painting, we've already built the stacking context tree. So instead of asking if a box establishes a stacking context, we can ask if its paintable *has* a stacking context. This was taking up ~6% of the profile when mousing around on the HTML specification. With this change, it disappears completely. :^)
2022-03-16 19:02:37 +01:00
// If `child` establishes its own stacking context, skip over it.
if (is<Layout::Box>(child) && child.paintable() && static_cast<Layout::Box const&>(child).paint_box()->stacking_context())
LibWeb: Don't paint children stacking contexts inside the current one
2021-07-23 13:16:04 +03:00
return;
LibWeb: Move StackingContext and PaintPhase into the Painting namespace
2022-03-10 02:13:28 +01:00
bool child_is_inline_or_replaced = child.is_inline() || is<Layout::ReplacedBox>(child);
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: 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
if (!child_is_inline_or_replaced && !child.is_floating() && !child.is_positioned()) {
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);
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);
}
break;
case StackingContextPaintPhase::Floats:
if (!child.is_positioned()) {
if (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);
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, StackingContextPaintPhase::BackgroundAndBorders);
}
paint_descendants(context, child, phase);
}
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:
if (!child.is_positioned()) {
if (child_is_inline_or_replaced) {
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);
paint_node(child, context, PaintPhase::Border);
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
paint_descendants(context, child, StackingContextPaintPhase::BackgroundAndBorders);
}
paint_descendants(context, child, phase);
}
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:
if (!child.is_positioned()) {
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::Foreground);
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;
case StackingContextPaintPhase::FocusAndOverlay:
if (context.has_focus()) {
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::FocusOutline);
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: 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: 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: 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
if (auto* paintable = box.paintable())
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 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
{
// 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: 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(m_box, context, PaintPhase::Background);
paint_node(m_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
auto paint_child = [&](auto* child) {
auto parent = child->m_box.parent();
auto* paintable = parent ? parent->paintable() : nullptr;
if (paintable)
paintable->before_children_paint(context, PaintPhase::Foreground);
child->paint(context);
if (paintable)
paintable->after_children_paint(context, PaintPhase::Foreground);
};
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 positioned descendants with negative z-indices (step 3)
for (auto* child : m_children) {
if (child->m_box.computed_values().z_index().has_value() && child->m_box.computed_values().z_index().value() < 0)
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
paint_child(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)
paint_descendants(context, m_box, StackingContextPaintPhase::BackgroundAndBorders);
// Draw the non-positioned floats (step 5)
paint_descendants(context, m_box, StackingContextPaintPhase::Floats);
// Draw inline content, replaced content, etc. (steps 6, 7)
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
paint_descendants(context, m_box, StackingContextPaintPhase::BackgroundAndBordersForInlineLevelAndReplaced);
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(m_box, context, PaintPhase::Foreground);
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, m_box, StackingContextPaintPhase::Foreground);
// Draw other positioned descendants (steps 8, 9)
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: 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
if (child->m_box.computed_values().z_index().has_value() && child->m_box.computed_values().z_index().value() < 0)
continue;
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
paint_child(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: 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(m_box, context, PaintPhase::FocusOutline);
paint_node(m_box, 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, m_box, StackingContextPaintPhase::FocusAndOverlay);
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
Gfx::FloatMatrix4x4 StackingContext::get_transformation_matrix(CSS::Transformation const& transformation) const
{
LibWeb: Support `transform: translate(...)` by percentage
2022-03-21 23:18:38 +01:00
auto count = transformation.values.size();
auto value = [this, transformation](size_t index, CSS::Length& reference) -> float {
return transformation.values[index].visit(
[this, reference](CSS::LengthPercentage const& value) {
return value.resolved(m_box, reference).to_px(m_box);
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: Support `transform: translate(...)` by percentage
2022-03-21 23:18:38 +01:00
[](float value) {
return value;
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: Support `transform: translate(...)` by percentage
2022-03-21 23:18:38 +01:00
};
LibWeb: Use paint tree traversal helpers in StackingContext
2022-04-08 15:56:18 +02:00
auto reference_box = paintable().absolute_rect();
LibWeb: Support `transform: translate(...)` by percentage
2022-03-21 23:18:38 +01:00
auto width = CSS::Length::make_px(reference_box.width());
auto height = CSS::Length::make_px(reference_box.height());
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
switch (transformation.function) {
case CSS::TransformFunction::Matrix:
LibWeb: Support `transform: translate(...)` by percentage
2022-03-21 23:18:38 +01:00
if (count == 6)
return Gfx::FloatMatrix4x4(value(0, width), value(2, width), 0, value(4, width),
value(1, height), value(3, height), 0, value(5, height),
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
0, 0, 1, 0,
0, 0, 0, 1);
break;
case CSS::TransformFunction::Translate:
LibWeb: Support `transform: translate(...)` by percentage
2022-03-21 23:18:38 +01:00
if (count == 1)
return Gfx::FloatMatrix4x4(1, 0, 0, value(0, width),
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
0, 1, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1);
LibWeb: Support `transform: translate(...)` by percentage
2022-03-21 23:18:38 +01:00
if (count == 2)
return Gfx::FloatMatrix4x4(1, 0, 0, value(0, width),
0, 1, 0, value(1, height),
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
0, 0, 1, 0,
0, 0, 0, 1);
break;
case CSS::TransformFunction::TranslateX:
LibWeb: Support `transform: translate(...)` by percentage
2022-03-21 23:18:38 +01:00
if (count == 1)
return Gfx::FloatMatrix4x4(1, 0, 0, value(0, width),
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
0, 1, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1);
break;
case CSS::TransformFunction::TranslateY:
LibWeb: Support `transform: translate(...)` by percentage
2022-03-21 23:18:38 +01:00
if (count == 1)
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
return Gfx::FloatMatrix4x4(1, 0, 0, 0,
LibWeb: Support `transform: translate(...)` by percentage
2022-03-21 23:18:38 +01:00
0, 1, 0, value(0, height),
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
0, 0, 1, 0,
0, 0, 0, 1);
break;
case CSS::TransformFunction::Scale:
LibWeb: Support `transform: translate(...)` by percentage
2022-03-21 23:18:38 +01:00
if (count == 1)
return Gfx::FloatMatrix4x4(value(0, width), 0, 0, 0,
0, value(0, height), 0, 0,
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
0, 0, 1, 0,
0, 0, 0, 1);
LibWeb: Support `transform: translate(...)` by percentage
2022-03-21 23:18:38 +01:00
if (count == 2)
return Gfx::FloatMatrix4x4(value(0, width), 0, 0, 0,
0, value(0, height), 0, 0,
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
0, 0, 1, 0,
0, 0, 0, 1);
break;
case CSS::TransformFunction::ScaleX:
LibWeb: Support `transform: translate(...)` by percentage
2022-03-21 23:18:38 +01:00
if (count == 1)
return Gfx::FloatMatrix4x4(value(0, width), 0, 0, 0,
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
0, 1, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1);
break;
case CSS::TransformFunction::ScaleY:
LibWeb: Support `transform: translate(...)` by percentage
2022-03-21 23:18:38 +01:00
if (count == 1)
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
return Gfx::FloatMatrix4x4(1, 0, 0, 0,
LibWeb: Support `transform: translate(...)` by percentage
2022-03-21 23:18:38 +01:00
0, value(0, height), 0, 0,
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
0, 0, 1, 0,
0, 0, 0, 1);
break;
default:
dbgln_if(LIBWEB_CSS_DEBUG, "FIXME: Unhandled transformation function {}", CSS::TransformationStyleValue::create(transformation.function, {})->to_string());
}
return Gfx::FloatMatrix4x4::identity();
}
Gfx::FloatMatrix4x4 StackingContext::combine_transformations(Vector<CSS::Transformation> const& transformations) const
{
auto matrix = Gfx::FloatMatrix4x4::identity();
for (auto const& transform : transformations)
matrix = matrix * get_transformation_matrix(transform);
return matrix;
}
// 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
Gfx::AffineTransform StackingContext::combine_transformations_2d(Vector<CSS::Transformation> const& transformations) const
{
auto matrix = combine_transformations(transformations);
auto* m = matrix.elements();
return Gfx::AffineTransform(m[0][0], m[1][0], m[0][1], m[1][1], m[0][3], m[1][3]);
}
LibWeb: Make StackingContext paint functions const
2022-03-10 15:44:43 +01:00
void StackingContext::paint(PaintContext& context) const
LibWeb: Draw elements with opacity in a separate stacking context
2021-07-23 13:19:16 +03:00
{
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
Gfx::PainterStateSaver saver(context.painter());
if (m_box.is_fixed_position()) {
context.painter().translate(context.scroll_offset());
}
LibWeb: Draw elements with opacity in a separate stacking context
2021-07-23 13:19:16 +03:00
auto opacity = m_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: 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
auto affine_transform = combine_transformations_2d(m_box.computed_values().transformations());
if (opacity < 1.0f || !affine_transform.is_identity()) {
LibGfx: Use ErrorOr<T> for Bitmap::try_create() Another one that was used in a fajillion places.
2021-11-06 19:30:59 +01:00
auto bitmap_or_error = Gfx::Bitmap::try_create(Gfx::BitmapFormat::BGRA8888, context.painter().target()->size());
if (bitmap_or_error.is_error())
LibWeb: Draw elements with opacity in a separate stacking context
2021-07-23 13:19:16 +03:00
return;
LibGfx: Use ErrorOr<T> for Bitmap::try_create() Another one that was used in a fajillion places.
2021-11-06 19:30:59 +01:00
auto bitmap = bitmap_or_error.release_value_but_fixme_should_propagate_errors();
Gfx::Painter painter(bitmap);
LibWeb: Use the correct painter for painting stacking contexts When cloning the PaintContext we should be using the painter backed by the bitmap created for this stacking context layer. Fixes: 54c3053bc3b0 ("LibWeb: Preserve paint state when painting...")
2022-04-08 19:42:57 +02:00
auto paint_context = context.clone(painter);
LibWeb: Draw elements with opacity in a separate stacking context
2021-07-23 13:19:16 +03:00
paint_internal(paint_context);
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: Apply the CSS transform-origin property We don't have transform-box yet, so this applies to the border-box for now. This also makes us pass a couple Web Platform Tests as well :^) For example: https://wpt.live/css/css-transforms/css3-transform-scale-002.html
2022-03-21 19:38:00 +01:00
auto transform_origin = this->transform_origin();
LibWeb: Use paint tree traversal helpers in StackingContext
2022-04-08 15:56:18 +02:00
auto source_rect = paintable().absolute_border_box_rect().translated(-transform_origin);
LibWeb: Include entire border box when painting stacking context layer For stacking contexts that have opacity between 0 and 1, and also contexts with a 2D transform, we first paint them into a temporary layer buffer. Then we blend that buffer with the contents in one go. Before this patch, we were only drawing the content box of the stacking context into this layer buffer, which led to padding and borders missing from elements painted this way.
2022-03-20 13:29:01 +01: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
auto transformed_destination_rect = affine_transform.map(source_rect).translated(transform_origin);
source_rect.translate_by(transform_origin);
LibWeb: Snap transformed stacking contexts to pixel grid Make sure that we're painting them at an integer pixel position, to avoid smearing.
2022-07-20 22:02:56 +02:00
// NOTE: If the destination and source rects are the same size, we round the source rect to ensure that it's pixel-aligned.
if (transformed_destination_rect.size() == source_rect.size())
context.painter().draw_scaled_bitmap(transformed_destination_rect.to_rounded<int>(), *bitmap, source_rect.to_rounded<int>(), opacity);
else
context.painter().draw_scaled_bitmap(transformed_destination_rect.to_rounded<int>(), *bitmap, source_rect, opacity, Gfx::Painter::ScalingMode::BilinearBlend);
LibWeb: Draw elements with opacity in a separate stacking context
2021-07-23 13:19:16 +03:00
} else {
paint_internal(context);
}
}
LibWeb: Apply the CSS transform-origin property We don't have transform-box yet, so this applies to the border-box for now. This also makes us pass a couple Web Platform Tests as well :^) For example: https://wpt.live/css/css-transforms/css3-transform-scale-002.html
2022-03-21 19:38:00 +01:00
Gfx::FloatPoint StackingContext::transform_origin() const
{
auto style_value = m_box.computed_values().transform_origin();
// FIXME: respect transform-box property
LibWeb: Use paint tree traversal helpers in StackingContext
2022-04-08 15:56:18 +02:00
auto reference_box = paintable().absolute_border_box_rect();
LibWeb: Apply the CSS transform-origin property We don't have transform-box yet, so this applies to the border-box for now. This also makes us pass a couple Web Platform Tests as well :^) For example: https://wpt.live/css/css-transforms/css3-transform-scale-002.html
2022-03-21 19:38:00 +01:00
auto x = reference_box.left() + style_value.x.resolved(m_box, CSS::Length::make_px(reference_box.width())).to_px(m_box);
auto y = reference_box.top() + style_value.y.resolved(m_box, CSS::Length::make_px(reference_box.height())).to_px(m_box);
return { x, y };
}
LibWeb: Make hit testing functions return Optional<HitTestResult> Using "HitTestResult with null paintable" as a way to signal misses was unnecessarily confusing. Let's use Optional instead. :^)
2022-03-21 11:11:05 +01:00
Optional<HitTestResult> StackingContext::hit_test(Gfx::FloatPoint const& position, HitTestType type) 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: Make hit testing respect hidden overflow
2022-07-03 18:34:51 -03:00
if (!m_box.is_visible())
return {};
if (m_box.computed_values().z_index().value_or(0) < 0)
return {};
LibWeb: Apply the CSS transform-origin property We don't have transform-box yet, so this applies to the border-box for now. This also makes us pass a couple Web Platform Tests as well :^) For example: https://wpt.live/css/css-transforms/css3-transform-scale-002.html
2022-03-21 19:38:00 +01:00
auto transform_origin = this->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
auto affine_transform = combine_transformations_2d(m_box.computed_values().transformations());
auto transformed_position = affine_transform.inverse().value_or({}).map(position - transform_origin) + transform_origin;
LibWeb: Make hit testing respect hidden overflow
2022-07-03 18:34:51 -03:00
// FIXME: Support more overflow variations.
if (paintable().computed_values().overflow_x() == CSS::Overflow::Hidden && paintable().computed_values().overflow_y() == CSS::Overflow::Hidden) {
if (!paintable().absolute_border_box_rect().contains(transformed_position.x(), transformed_position.y()))
return {};
}
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).
for (ssize_t i = m_children.size() - 1; i >= 0; --i) {
auto const& child = *m_children[i];
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
auto result = child.hit_test(transformed_position, type);
LibWeb: Make hit testing functions return Optional<HitTestResult> Using "HitTestResult with null paintable" as a way to signal misses was unnecessarily confusing. Let's use Optional instead. :^)
2022-03-21 11:11:05 +01:00
if (result.has_value())
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
return result;
}
LibWeb: Make hit testing functions return Optional<HitTestResult> Using "HitTestResult with null paintable" as a way to signal misses was unnecessarily confusing. Let's use Optional instead. :^)
2022-03-21 11:11:05 +01:00
Optional<HitTestResult> result;
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: Use paint tree traversal helpers in StackingContext
2022-04-08 15:56:18 +02:00
paintable().for_each_in_subtree_of_type<PaintableBox>([&](auto& paint_box) {
LibWeb: Make hit testing respect hidden overflow
2022-07-03 18:34:51 -03:00
// FIXME: Support more overflow variations.
if (paint_box.computed_values().overflow_x() == CSS::Overflow::Hidden && paint_box.computed_values().overflow_y() == CSS::Overflow::Hidden) {
if (!paint_box.absolute_border_box_rect().contains(transformed_position.x(), transformed_position.y()))
return TraversalDecision::SkipChildrenAndContinue;
}
LibWeb: Use paint tree traversal helpers in StackingContext
2022-04-08 15:56:18 +02:00
auto& layout_box = paint_box.layout_box();
if (layout_box.is_positioned() && !paint_box.stacking_context()) {
if (auto candidate = paint_box.hit_test(transformed_position, type); candidate.has_value())
LibWeb: Fix O(n^2) traversal in hit testing We already walk the entire paint tree within each stacking context in the main hit testing function (StackingContext::hit_test()), so there's no need for each individual paintable to walk its own children again. By not doing that, we remove a source of O(n^2) traversal which made hit testing on deeply nested web pages unbearably slow.
2022-03-21 12:12:50 +01:00
result = move(candidate);
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: Make hit testing respect hidden overflow
2022-07-03 18:34:51 -03:00
return TraversalDecision::Continue;
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: Make hit testing functions return Optional<HitTestResult> Using "HitTestResult with null paintable" as a way to signal misses was unnecessarily confusing. Let's use Optional instead. :^)
2022-03-21 11:11:05 +01:00
if (result.has_value())
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
return result;
// 5. the in-flow, inline-level, non-positioned descendants, including inline tables and inline blocks.
LibWeb: Move StackingContext and PaintPhase into the Painting namespace
2022-03-10 02:13:28 +01:00
if (m_box.children_are_inline() && is<Layout::BlockContainer>(m_box)) {
LibWeb: Use paint tree traversal helpers in StackingContext
2022-04-08 15:56:18 +02:00
auto result = paintable().hit_test(transformed_position, type);
LibWeb: Make hit testing functions return Optional<HitTestResult> Using "HitTestResult with null paintable" as a way to signal misses was unnecessarily confusing. Let's use Optional instead. :^)
2022-03-21 11:11:05 +01:00
if (result.has_value())
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
return result;
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: Use paint tree traversal helpers in StackingContext
2022-04-08 15:56:18 +02:00
paintable().for_each_in_subtree_of_type<PaintableBox>([&](auto const& paint_box) {
LibWeb: Make hit testing respect hidden overflow
2022-07-03 18:34:51 -03:00
// FIXME: Support more overflow variations.
if (paint_box.computed_values().overflow_x() == CSS::Overflow::Hidden && paint_box.computed_values().overflow_y() == CSS::Overflow::Hidden) {
if (!paint_box.absolute_border_box_rect().contains(transformed_position.x(), transformed_position.y()))
return TraversalDecision::SkipChildrenAndContinue;
}
LibWeb: Use paint tree traversal helpers in StackingContext
2022-04-08 15:56:18 +02:00
auto& layout_box = paint_box.layout_box();
if (layout_box.is_floating()) {
if (auto candidate = paint_box.hit_test(transformed_position, type); candidate.has_value())
LibWeb: Fix O(n^2) traversal in hit testing We already walk the entire paint tree within each stacking context in the main hit testing function (StackingContext::hit_test()), so there's no need for each individual paintable to walk its own children again. By not doing that, we remove a source of O(n^2) traversal which made hit testing on deeply nested web pages unbearably slow.
2022-03-21 12:12:50 +01:00
result = move(candidate);
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: Make hit testing respect hidden overflow
2022-07-03 18:34:51 -03:00
return TraversalDecision::Continue;
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: Make hit testing functions return Optional<HitTestResult> Using "HitTestResult with null paintable" as a way to signal misses was unnecessarily confusing. Let's use Optional instead. :^)
2022-03-21 11:11:05 +01:00
if (result.has_value())
return result;
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.
if (!m_box.children_are_inline()) {
LibWeb: Use paint tree traversal helpers in StackingContext
2022-04-08 15:56:18 +02:00
paintable().for_each_in_subtree_of_type<PaintableBox>([&](auto const& paint_box) {
LibWeb: Make hit testing respect hidden overflow
2022-07-03 18:34:51 -03:00
// FIXME: Support more overflow variations.
if (paint_box.computed_values().overflow_x() == CSS::Overflow::Hidden && paint_box.computed_values().overflow_y() == CSS::Overflow::Hidden) {
if (!paint_box.absolute_border_box_rect().contains(transformed_position.x(), transformed_position.y()))
return TraversalDecision::SkipChildrenAndContinue;
}
LibWeb: Use paint tree traversal helpers in StackingContext
2022-04-08 15:56:18 +02:00
auto& layout_box = paint_box.layout_box();
if (!layout_box.is_absolutely_positioned() && !layout_box.is_floating()) {
if (auto candidate = paint_box.hit_test(transformed_position, type); candidate.has_value())
LibWeb: Fix O(n^2) traversal in hit testing We already walk the entire paint tree within each stacking context in the main hit testing function (StackingContext::hit_test()), so there's no need for each individual paintable to walk its own children again. By not doing that, we remove a source of O(n^2) traversal which made hit testing on deeply nested web pages unbearably slow.
2022-03-21 12:12:50 +01:00
result = move(candidate);
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: Make hit testing respect hidden overflow
2022-07-03 18:34:51 -03:00
return TraversalDecision::Continue;
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: Make hit testing functions return Optional<HitTestResult> Using "HitTestResult with null paintable" as a way to signal misses was unnecessarily confusing. Let's use Optional instead. :^)
2022-03-21 11:11:05 +01:00
if (result.has_value())
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
return result;
}
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).
for (ssize_t i = m_children.size() - 1; i >= 0; --i) {
auto const& child = *m_children[i];
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
auto result = child.hit_test(transformed_position, type);
LibWeb: Make hit testing functions return Optional<HitTestResult> Using "HitTestResult with null paintable" as a way to signal misses was unnecessarily confusing. Let's use Optional instead. :^)
2022-03-21 11:11:05 +01:00
if (result.has_value())
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
return result;
}
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
// 1. the background and borders of the element forming the stacking context.
LibWeb: Use paint tree traversal helpers in StackingContext
2022-04-08 15:56:18 +02:00
if (paintable().absolute_border_box_rect().contains(transformed_position)) {
LibWeb: Move hit testing to the painting tree
2022-03-11 00:03:28 +01:00
return HitTestResult {
LibWeb: Use paint tree traversal helpers in StackingContext
2022-04-08 15:56:18 +02:00
.paintable = paintable(),
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: 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
return {};
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: Use paint tree traversal helpers in StackingContext
2022-04-08 15:56:18 +02:00
builder.appendff("SC for {} {} [children: {}] (z-index: ", m_box.debug_description(), paintable().absolute_rect(), m_children.size());
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
if (m_box.computed_values().z_index().has_value())
builder.appendff("{}", m_box.computed_values().z_index().value());
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
auto affine_transform = combine_transformations_2d(m_box.computed_values().transformations());
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