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/Userland/Libraries/LibWeb/Painting/StackingContext.cpp

690 lines
32 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: 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: 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: Add proper support for Angle parameters in transform functions Also, made the `reference_length` parameter optional for the lambda that extracts transform-function parameters, since it is only needed to resolve `LengthPercentage` parameters.
2022-07-14 17:45:23 +01:00
#include <AK/ExtraMathConstants.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: Teach CSS transformed StackingContexts about image-rendering Previously, all StackingContexts which were scaled using CSS transforms were hard-coded to use BilinearBlend. This fix maps specified image-rendering properties to reasonable ScalingModes for painting.
2023-06-08 23:57:53 +03:00
#include <LibWeb/CSS/ComputedValues.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: 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: Some improvements for painting of collapsed table borders Follow the specification in making the borders centered on the grid lines. This avoids visual bugs due to double-rendering of borders on either side of an edge and paves the way for a full implementation of the harmonization algorithm for collapsed borders. Currently, this still lacks complete handling of row and column spans. Also, the box model for cells still considers the full width of the internal borders instead of just half, as the specification requires. Some additional handling of rounding issues will be needed to avoid very subtle visual bugs. Despite these limitations, this improves the appearance of all the tables with collapsed borders I've tried while limiting the amount of change to something reasonable.
2023-07-01 03:06:21 +00:00
#include <LibWeb/Painting/TableBordersPainting.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/Painting: Translate by scroll offset before painting descendants Fixes painting of nested nodes in scrollable containers by moving painter's scroll offset translation from paint_node() to before_children_paint() and after_children_paint().
2023-08-08 15:02:35 +02: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: 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
StackingContext::StackingContext(Layout::Box& box, StackingContext* parent, size_t 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
: m_box(box)
LibJS+LibWeb: Wrap raw JS::Cell*/& fields in GCPtr/NonnullGCPtr
2023-02-26 16:09:02 -07:00
, m_transform(combine_transformations(m_box->computed_values().transformations()))
LibWeb: Compute StackingContext transform origin only once When mousing over twitter, 17% of time was spent computing stacking context transform origins. Since this never changes after the stacking context is created, we can cache it and avoid all that work.
2022-09-24 20:36:06 +02:00
, m_transform_origin(compute_transform_origin())
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) {
LibJS+LibWeb: Wrap raw JS::Cell*/& fields in GCPtr/NonnullGCPtr
2023-02-26 16:09:02 -07:00
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);
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: 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: StackingContext::paint_descendants() can take const layout node It doesn't mutate the layout tree in any way.
2022-10-23 17:59:32 +02:00
void StackingContext::paint_descendants(PaintContext& context, Layout::Node const& box, StackingContextPaintPhase phase) const
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: 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 (auto* paintable = box.paintable()) {
LibWeb: Clip hidden overflow by absolute rect of containing block Since handling overflow: hidden in PaintableBox::before_children_paint while following paint traversal order can't result in correctly computed clip rectangle for elements that create their own stacking context (because before_children_paint is called only for parent but overflow: hidden can be set somewhere deeper but not in direct ancestor), here introduced new function PaintableBox::clip_rect() that computes clip rectangle by looking into containing block. should_clip_overflow flag that disables clip for absolutely positioned elements in before_children_paint and after_children_paint is removed because after changing clip rectangle to be computed from not parent but containing block it is not needed anymore (absolutely positioned item is clipped if it's containing block has hidden overflow)
2022-11-12 00:07:43 +03:00
paintable->before_children_paint(context, to_paint_phase(phase));
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
paintable->apply_clip_overflow_rect(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: 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
auto child_stacking_context = [&](auto& child) -> StackingContext const* {
if (auto* paintable = child.paintable()) {
if (auto* stacking_context = paintable->stacking_context_rooted_here())
return stacking_context;
}
return nullptr;
};
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 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
auto* stacking_context = child_stacking_context(child);
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
if (child.is_positioned()) {
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 `child` is positioned with a z-index of `0` or `auto`, skip over it.
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
auto const& z_index = child.computed_values().z_index();
if (!z_index.has_value() || z_index.value() == 0)
return;
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
// Skip positioned children with stacking contexts, these are handled in paint_internal().
if (stacking_context)
return;
}
if (stacking_context) {
// FIXME: This may not be fully correct with respect to the paint phases.
if (phase == StackingContextPaintPhase::Foreground)
paint_child(context, *stacking_context);
// Note: Don't further recuse into descendants as paint_child() will do that.
return;
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: 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: 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: Snap table grid to device pixels in separate borders mode Build a grid snapped to device pixels and use it to construct the rectangles for the cell edges, same as for collapsed borders. This is especially important when border-spacing is set to 0 since it avoids gaps between adjacent cells which have borders set.
2023-08-03 03:48:37 +00:00
bool is_table_with_collapsed_borders = child.display().is_table_inside() && child.computed_values().border_collapse() == CSS::BorderCollapse::Collapse;
if (!child.display().is_table_cell() && !is_table_with_collapsed_borders)
LibWeb: Move collapsed table border painting to a separate function Move painting of cell borders to a separated function since doing it correctly has to consider the entire grid as a whole for the collapsed borders case.
2023-06-27 02:13:29 +00: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: Snap table grid to device pixels in separate borders mode Build a grid snapped to device pixels and use it to construct the rectangles for the cell edges, same as for collapsed borders. This is especially important when border-spacing is set to 0 since it avoids gaps between adjacent cells which have borders set.
2023-08-03 03:48:37 +00:00
if (child.display().is_table_inside() || child.computed_values().border_collapse() == CSS::BorderCollapse::Collapse) {
paint_table_borders(context, 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
}
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: Paint separate borders for inline tables
2023-08-14 09:24:48 +00:00
if (child.display().is_table_inside() && child.computed_values().border_collapse() == CSS::BorderCollapse::Separate)
paint_table_borders(context, child);
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: 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: 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 (auto* paintable = box.paintable()) {
paintable->clear_clip_overflow_rect(context, to_paint_phase(phase));
LibWeb: Clip hidden overflow by absolute rect of containing block Since handling overflow: hidden in PaintableBox::before_children_paint while following paint traversal order can't result in correctly computed clip rectangle for elements that create their own stacking context (because before_children_paint is called only for parent but overflow: hidden can be set somewhere deeper but not in direct ancestor), here introduced new function PaintableBox::clip_rect() that computes clip rectangle by looking into containing block. should_clip_overflow flag that disables clip for absolutely positioned elements in before_children_paint and after_children_paint is removed because after changing clip rectangle to be computed from not parent but containing block it is not needed anymore (absolutely positioned item is clipped if it's containing block has hidden overflow)
2022-11-12 00:07:43 +03:00
paintable->after_children_paint(context, to_paint_phase(phase));
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
}
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: 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
void StackingContext::paint_child(PaintContext& context, StackingContext const& child) const
{
auto parent = child.m_box->parent();
auto* parent_paintable = parent ? parent->paintable() : nullptr;
if (parent_paintable)
parent_paintable->before_children_paint(context, PaintPhase::Foreground);
auto containing_block = child.m_box->containing_block();
auto* containing_block_paintable = containing_block ? containing_block->paintable() : nullptr;
if (containing_block_paintable)
containing_block_paintable->apply_clip_overflow_rect(context, PaintPhase::Foreground);
child.paint(context);
if (parent_paintable)
parent_paintable->after_children_paint(context, PaintPhase::Foreground);
if (containing_block_paintable)
containing_block_paintable->clear_clip_overflow_rect(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
{
// 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
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: 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: 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 (!child->paintable_box().layout_box().is_positioned())
continue;
if (child->paintable_box().computed_values().z_index().has_value() && child->m_box->computed_values().z_index().value() < 0)
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)
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);
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)
// FIXME: There's more to this step that we have yet to understand and implement.
LibWeb: Paint relatively positioned inline-level elements Since we deliberately skip positioned elements in paint_descendants(), we have to make sure we actually paint them in the subsequent paint_internal() pass. Before this change, we were only painting positioned elements whose paintable was a PaintableBox, neglecting inline-level relpos elements.
2023-07-14 10:03:14 +02:00
m_box->paintable_box()->for_each_in_subtree([&](Paintable const& paintable) {
auto const& layout_node = paintable.layout_node();
auto const& z_index = paintable.computed_values().z_index();
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 (!layout_node.is_positioned() || (z_index.has_value() && z_index.value() != 0)) {
return paintable.stacking_context_rooted_here()
? TraversalDecision::SkipChildrenAndContinue
: TraversalDecision::Continue;
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
// 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: Paint relatively positioned inline-level elements Since we deliberately skip positioned elements in paint_descendants(), we have to make sure we actually paint them in the subsequent paint_internal() pass. Before this change, we were only painting positioned elements whose paintable was a PaintableBox, neglecting inline-level relpos elements.
2023-07-14 10:03:14 +02:00
auto parent = layout_node.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
auto* parent_paintable = parent ? parent->paintable() : nullptr;
if (parent_paintable)
parent_paintable->before_children_paint(context, PaintPhase::Foreground);
LibWeb: Paint relatively positioned inline-level elements Since we deliberately skip positioned elements in paint_descendants(), we have to make sure we actually paint them in the subsequent paint_internal() pass. Before this change, we were only painting positioned elements whose paintable was a PaintableBox, neglecting inline-level relpos elements.
2023-07-14 10:03:14 +02:00
auto containing_block = layout_node.containing_block();
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
auto* containing_block_paintable = containing_block ? containing_block->paintable() : nullptr;
if (containing_block_paintable)
containing_block_paintable->apply_clip_overflow_rect(context, PaintPhase::Foreground);
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 (auto* child = paintable.stacking_context_rooted_here()) {
paint_child(context, *child);
return TraversalDecision::SkipChildrenAndContinue;
} else {
paint_node(layout_node, context, PaintPhase::Background);
paint_node(layout_node, context, PaintPhase::Border);
paint_descendants(context, layout_node, StackingContextPaintPhase::BackgroundAndBorders);
paint_descendants(context, layout_node, StackingContextPaintPhase::Floats);
paint_descendants(context, layout_node, StackingContextPaintPhase::BackgroundAndBordersForInlineLevelAndReplaced);
paint_node(layout_node, context, PaintPhase::Foreground);
paint_descendants(context, layout_node, StackingContextPaintPhase::Foreground);
paint_node(layout_node, context, PaintPhase::Outline);
paint_node(layout_node, context, PaintPhase::Overlay);
paint_descendants(context, layout_node, StackingContextPaintPhase::FocusAndOverlay);
}
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);
if (containing_block_paintable)
containing_block_paintable->clear_clip_overflow_rect(context, PaintPhase::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
return TraversalDecision::Continue;
});
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: 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: 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 (!child->paintable_box().layout_box().is_positioned())
continue;
if (child->paintable_box().computed_values().z_index().has_value() && child->m_box->computed_values().z_index().value() >= 1)
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: Rename PaintPhase::FocusOutline -> Outline Any element can have an outline, whether because of focus or not.
2023-08-02 13:58:34 +01:00
paint_node(m_box, 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(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();
LibWeb: Resolve calc() values in CSS transform There are two parts to this fix: - First, StyleProperties::transformations() would previously omit calc() values entirely when returning the list of transformations. This was very confusing to StackingContext which then tried to index into the list based on faulty assumptions. Fix this by emitting calc values. - Second, StackingContext::get_transformation_matrix() now always calls resolve() on length-percentages. This takes care of actually resolving calc() values. If no reference value for percentages is provided, we default to 0px. This stops LibWeb from asserting on websites with calc() in transform values, such as https://qt.io/ :^)
2023-07-15 10:23:43 +02:00
auto value = [this, transformation](size_t index, CSS::Length const& reference_length = CSS::Length::make_px(0)) -> float {
LibWeb: Support `transform: translate(...)` by percentage
2022-03-21 23:18:38 +01:00
return transformation.values[index].visit(
LibWeb: Change calc node representation from float to double
2023-05-27 21:10:21 +02:00
[this, reference_length](CSS::LengthPercentage const& value) -> double {
LibWeb: Resolve calc() values in CSS transform There are two parts to this fix: - First, StyleProperties::transformations() would previously omit calc() values entirely when returning the list of transformations. This was very confusing to StackingContext which then tried to index into the list based on faulty assumptions. Fix this by emitting calc values. - Second, StackingContext::get_transformation_matrix() now always calls resolve() on length-percentages. This takes care of actually resolving calc() values. If no reference value for percentages is provided, we default to 0px. This stops LibWeb from asserting on websites with calc() in transform values, such as https://qt.io/ :^)
2023-07-15 10:23:43 +02:00
return value.resolved(m_box, reference_length).to_px(m_box).to_float();
LibWeb: Add proper support for Angle parameters in transform functions Also, made the `reference_length` parameter optional for the lambda that extracts transform-function parameters, since it is only needed to resolve `LengthPercentage` parameters.
2022-07-14 17:45:23 +01:00
},
LibWeb: Remove CalculatedStyleValue from Angle ...and replace it with AngleOrCalculated. This has the nice bonus effect of actually handling `calc()` for angles in a transform function. :^) (Previously we just would have asserted.)
2023-03-30 15:33:37 +01:00
[this](CSS::AngleOrCalculated const& value) {
LibWeb: Change calc node representation from float to double
2023-05-27 21:10:21 +02:00
return value.resolved(m_box).to_degrees() * M_DEG2RAD;
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: Change calc node representation from float to double
2023-05-27 21:10:21 +02:00
[](double value) {
LibWeb: Support `transform: translate(...)` by percentage
2022-03-21 23:18:38 +01:00
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/Painting: Rename StackingContext::paintable{ => _box}() It returns a PaintableBox, not any Paintable.
2023-04-20 16:00:21 +01:00
auto reference_box = paintable_box().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)
LibWeb: Add proper support for Angle parameters in transform functions Also, made the `reference_length` parameter optional for the lambda that extracts transform-function parameters, since it is only needed to resolve `LengthPercentage` parameters.
2022-07-14 17:45:23 +01:00
return Gfx::FloatMatrix4x4(value(0), value(2), 0, value(4),
value(1), value(3), 0, value(5),
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;
LibWeb: Implement matrix3d transform function from css-transforms-2
2022-10-01 01:57:54 +01:00
case CSS::TransformFunction::Matrix3d:
if (count == 16)
return Gfx::FloatMatrix4x4(value(0), value(4), value(8), value(12),
value(1), value(5), value(9), value(13),
value(2), value(6), value(10), value(14),
value(3), value(7), value(11), value(15));
break;
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
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;
LibWeb: Support translate3d
2022-10-28 02:46:27 +03:00
case CSS::TransformFunction::Translate3d:
return Gfx::FloatMatrix4x4(1, 0, 0, value(0, width),
0, 1, 0, value(1, height),
0, 0, 1, value(2),
0, 0, 0, 1);
break;
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
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)
LibWeb: Add proper support for Angle parameters in transform functions Also, made the `reference_length` parameter optional for the lambda that extracts transform-function parameters, since it is only needed to resolve `LengthPercentage` parameters.
2022-07-14 17:45:23 +01:00
return Gfx::FloatMatrix4x4(value(0), 0, 0, 0,
0, value(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, 0, 1, 0,
0, 0, 0, 1);
LibWeb: Support `transform: translate(...)` by percentage
2022-03-21 23:18:38 +01:00
if (count == 2)
LibWeb: Add proper support for Angle parameters in transform functions Also, made the `reference_length` parameter optional for the lambda that extracts transform-function parameters, since it is only needed to resolve `LengthPercentage` parameters.
2022-07-14 17:45:23 +01:00
return Gfx::FloatMatrix4x4(value(0), 0, 0, 0,
LibWeb: Don't scale by x, x when a scale x, y is provided as a transform
2022-10-01 01:47:02 +02:00
0, value(1), 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)
LibWeb: Add proper support for Angle parameters in transform functions Also, made the `reference_length` parameter optional for the lambda that extracts transform-function parameters, since it is only needed to resolve `LengthPercentage` parameters.
2022-07-14 17:45:23 +01:00
return Gfx::FloatMatrix4x4(value(0), 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: Add proper support for Angle parameters in transform functions Also, made the `reference_length` parameter optional for the lambda that extracts transform-function parameters, since it is only needed to resolve `LengthPercentage` parameters.
2022-07-14 17:45:23 +01:00
0, value(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, 0, 1, 0,
0, 0, 0, 1);
break;
LibWeb: Implement rotation transform functions from css-transforms-2
2022-10-01 01:57:13 +01:00
case CSS::TransformFunction::RotateX:
if (count == 1)
return Gfx::rotation_matrix({ 1.0f, 0.0f, 0.0f }, value(0));
break;
case CSS::TransformFunction::RotateY:
if (count == 1)
return Gfx::rotation_matrix({ 0.0f, 1.0f, 0.0f }, value(0));
break;
LibWeb: Produce a transformation matrix for TransformFunction::Rotate Currently we can't actually paint the result, but at least the maths is correct. :^)
2022-07-21 14:29:47 +01:00
case CSS::TransformFunction::Rotate:
LibWeb: Implement rotation transform functions from css-transforms-2
2022-10-01 01:57:13 +01:00
case CSS::TransformFunction::RotateZ:
LibWeb: Produce a transformation matrix for TransformFunction::Rotate Currently we can't actually paint the result, but at least the maths is correct. :^)
2022-07-21 14:29:47 +01:00
if (count == 1)
return Gfx::rotation_matrix({ 0.0f, 0.0f, 1.0f }, value(0));
break;
LibWeb: Support skew{X,Y} in stacking context transforms https://drafts.csswg.org/css-transforms/#SkewDefined
2023-08-09 19:59:54 +01:00
case CSS::TransformFunction::Skew:
if (count == 1)
return Gfx::FloatMatrix4x4(1, tanf(value(0)), 0, 0,
0, 1, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1);
if (count == 2)
return Gfx::FloatMatrix4x4(1, tanf(value(0)), 0, 0,
tanf(value(1)), 1, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1);
break;
case CSS::TransformFunction::SkewX:
if (count == 1)
return Gfx::FloatMatrix4x4(1, tanf(value(0)), 0, 0,
0, 1, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1);
break;
case CSS::TransformFunction::SkewY:
if (count == 1)
return Gfx::FloatMatrix4x4(1, 0, 0, 0,
tanf(value(0)), 1, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1);
break;
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
default:
LibWeb: Propagate errors from StyleValue construction Turns out we create a lot of these, mostly from places that don't return ErrorOr. The yak stack grows.
2023-05-05 15:02:03 +01:00
dbgln_if(LIBWEB_CSS_DEBUG, "FIXME: Unhandled transformation function {}", MUST(CSS::TransformationStyleValue::create(transformation.function, {}))->to_string());
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::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
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: 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* m = m_transform.elements();
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::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());
LibJS+LibWeb: Wrap raw JS::Cell*/& fields in GCPtr/NonnullGCPtr
2023-02-26 16:09:02 -07:00
if (m_box->is_fixed_position()) {
LibWeb: Reset painter translation when painting fixed-position elements This makes nested position:fixed elements work, previously we'd apply the viewport scroll offset once at every nesting level.
2022-10-01 14:04:22 +02:00
context.painter().translate(-context.painter().translation());
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
}
LibJS+LibWeb: Wrap raw JS::Cell*/& fields in GCPtr/NonnullGCPtr
2023-02-26 16:09:02 -07: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: 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: Transform translate() values to device pixels before painting
2023-02-18 23:27:53 +03:00
auto translation = context.rounded_device_point(affine_transform.translation().to_type<CSSPixels>()).to_type<int>().to_type<float>();
affine_transform.set_translation(translation);
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 draw only-translated stacking contexts via bitmap If the 2D transform in effect is just a simple translation, we don't need to draw into a temporary bitmap and then transform it. We can just translate the painter. :^)
2022-09-29 01:20:13 +02:00
if (opacity < 1.0f || !affine_transform.is_identity_or_translation()) {
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
auto transform_origin = this->transform_origin();
LibWeb/Painting: Rename StackingContext::paintable{ => _box}() It returns a PaintableBox, not any Paintable.
2023-04-20 16:00:21 +01:00
auto source_rect = context.enclosing_device_rect(paintable_box().absolute_paint_rect()).to_type<int>().to_type<float>().translated(-transform_origin);
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
auto transformed_destination_rect = affine_transform.map(source_rect).translated(transform_origin);
auto destination_rect = transformed_destination_rect.to_rounded<int>();
// FIXME: We should find a way to scale the paintable, rather than paint into a separate bitmap,
// then scale it. This snippet now copies the background at the destination, then scales it down/up
// to the size of the source (which could add some artefacts, though just scaling the bitmap already does that).
// We need to copy the background at the destination because a bunch of our rendering effects now rely on
// being able to sample the painter (see border radii, shadows, filters, etc).
LibWeb: Convert Paintable coordinates to new pixel units This fixes a few sizing issues too. The page size is now correct in most cases! \o/ We get to remove some of the `to_type<>()` shenanigans, though it reappears in some other places.
2022-10-31 19:46:55 +00:00
CSSPixelPoint destination_clipped_fixup {};
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
auto try_get_scaled_destination_bitmap = [&]() -> ErrorOr<NonnullRefPtr<Gfx::Bitmap>> {
LibWeb: Fix destination bitmap edge clip case in transform painting This fixes an edge case, where the destination rect falls partly outside the painter, so is clipped to a smaller size in `get_region_bitmap()` (which needs to be accounted for with an extra offset).
2022-09-26 00:01:31 +01:00
Gfx::IntRect actual_destination_rect;
auto bitmap = TRY(context.painter().get_region_bitmap(destination_rect, Gfx::BitmapFormat::BGRA8888, actual_destination_rect));
// get_region_bitmap() may clip to a smaller region if the requested rect goes outside the painter, so we need to account for that.
LibWeb: Convert Paintable coordinates to new pixel units This fixes a few sizing issues too. The page size is now correct in most cases! \o/ We get to remove some of the `to_type<>()` shenanigans, though it reappears in some other places.
2022-10-31 19:46:55 +00:00
destination_clipped_fixup = CSSPixelPoint { destination_rect.location() - actual_destination_rect.location() };
LibWeb: Fix destination bitmap edge clip case in transform painting This fixes an edge case, where the destination rect falls partly outside the painter, so is clipped to a smaller size in `get_region_bitmap()` (which needs to be accounted for with an extra offset).
2022-09-26 00:01:31 +01:00
destination_rect = actual_destination_rect;
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
if (source_rect.size() != transformed_destination_rect.size()) {
LibWeb: Fix destination bitmap edge clip case in transform painting This fixes an edge case, where the destination rect falls partly outside the painter, so is clipped to a smaller size in `get_region_bitmap()` (which needs to be accounted for with an extra offset).
2022-09-26 00:01:31 +01:00
auto sx = static_cast<float>(source_rect.width()) / transformed_destination_rect.width();
auto sy = static_cast<float>(source_rect.height()) / transformed_destination_rect.height();
bitmap = TRY(bitmap->scaled(sx, sy));
destination_clipped_fixup.scale_by(sx, sy);
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
}
return bitmap;
};
auto bitmap_or_error = try_get_scaled_destination_bitmap();
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
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/Painting: Rename StackingContext::paintable{ => _box}() It returns a PaintableBox, not any Paintable.
2023-04-20 16:00:21 +01:00
painter.translate(context.rounded_device_point(-paintable_box().absolute_paint_rect().location() + destination_clipped_fixup).to_type<int>());
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: Teach CSS transformed StackingContexts about image-rendering Previously, all StackingContexts which were scaled using CSS transforms were hard-coded to use BilinearBlend. This fix maps specified image-rendering properties to reasonable ScalingModes for painting.
2023-06-08 23:57:53 +03:00
if (destination_rect.size() == bitmap->size()) {
LibWeb: Fix destination bitmap edge clip case in transform painting This fixes an edge case, where the destination rect falls partly outside the painter, so is clipped to a smaller size in `get_region_bitmap()` (which needs to be accounted for with an extra offset).
2022-09-26 00:01:31 +01:00
context.painter().blit(destination_rect.location(), *bitmap, bitmap->rect(), opacity);
LibWeb: Teach CSS transformed StackingContexts about image-rendering Previously, all StackingContexts which were scaled using CSS transforms were hard-coded to use BilinearBlend. This fix maps specified image-rendering properties to reasonable ScalingModes for painting.
2023-06-08 23:57:53 +03:00
} else {
auto scaling_mode = CSS::to_gfx_scaling_mode(m_box->computed_values().image_rendering(), bitmap->rect(), destination_rect);
context.painter().draw_scaled_bitmap(destination_rect, *bitmap, bitmap->rect(), opacity, scaling_mode);
}
LibWeb: Draw elements with opacity in a separate stacking context
2021-07-23 13:19:16 +03:00
} else {
LibWeb: Don't draw only-translated stacking contexts via bitmap If the 2D transform in effect is just a simple translation, we don't need to draw into a temporary bitmap and then transform it. We can just translate the painter. :^)
2022-09-29 01:20:13 +02:00
Gfx::PainterStateSaver saver(context.painter());
context.painter().translate(affine_transform.translation().to_rounded<int>());
LibWeb: Draw elements with opacity in a separate stacking context
2021-07-23 13:19:16 +03:00
paint_internal(context);
}
}
LibWeb: Compute StackingContext transform origin only once When mousing over twitter, 17% of time was spent computing stacking context transform origins. Since this never changes after the stacking context is created, we can cache it and avoid all that work.
2022-09-24 20:36:06 +02:00
Gfx::FloatPoint StackingContext::compute_transform_origin() const
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
{
LibJS+LibWeb: Wrap raw JS::Cell*/& fields in GCPtr/NonnullGCPtr
2023-02-26 16:09:02 -07:00
auto style_value = m_box->computed_values().transform_origin();
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
// FIXME: respect transform-box property
LibWeb/Painting: Rename StackingContext::paintable{ => _box}() It returns a PaintableBox, not any Paintable.
2023-04-20 16:00:21 +01:00
auto reference_box = paintable_box().absolute_border_box_rect();
LibWeb: Use the new to_px() helpers in CSS, SVG and layout code There should be no behavior change from this, only slightly less verbosity. :^)
2023-05-06 16:34:55 +02:00
auto x = reference_box.left() + style_value.x.to_px(m_box, reference_box.width());
auto y = reference_box.top() + style_value.y.to_px(m_box, reference_box.height());
LibWeb+WebContent: Forbid access to underlying type of CSSPixels Although DistinctNumeric, which is supposed to abstract the underlying type, was used to represent CSSPixels, we have a whole bunch of places in the layout code that assume CSSPixels::value() returns a floating-point type. This assumption makes it difficult to replace the underlying type in CSSPixels with a non-floating type. To make it easier to transition CSSPixels to fixed-point math, one step we can take is to prevent access to the underlying type using value() and instead use explicit conversions with the to_float(), to_double(), and to_int() methods.
2023-06-12 21:37:35 +03:00
return { x.to_float(), y.to_float() };
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
}
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
template<typename U, typename Callback>
static TraversalDecision for_each_in_inclusive_subtree_of_type_within_same_stacking_context_in_reverse(Paintable const& paintable, Callback callback)
{
LibWeb: Add Paintable::stacking_context_rooted_here() This is a convenience helper that lets you get the stacking context rooted at a given paintable, without checking that the paintable is a box first.
2023-07-14 10:02:19 +02:00
if (paintable.stacking_context_rooted_here()) {
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
// Note: Include the stacking context (so we can hit test it), but don't recurse into it.
if (auto decision = callback(static_cast<U const&>(paintable)); decision != TraversalDecision::Continue)
return decision;
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::SkipChildrenAndContinue;
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
}
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
for (auto* child = paintable.last_child(); child; child = child->previous_sibling()) {
if (for_each_in_inclusive_subtree_of_type_within_same_stacking_context_in_reverse<U>(*child, callback) == TraversalDecision::Break)
return TraversalDecision::Break;
}
if (is<U>(paintable)) {
if (auto decision = callback(static_cast<U const&>(paintable)); decision != TraversalDecision::Continue)
return decision;
}
return TraversalDecision::Continue;
}
template<typename U, typename Callback>
static TraversalDecision for_each_in_subtree_of_type_within_same_stacking_context_in_reverse(Paintable const& paintable, Callback callback)
{
for (auto* child = paintable.last_child(); child; child = child->previous_sibling()) {
if (for_each_in_inclusive_subtree_of_type_within_same_stacking_context_in_reverse<U>(*child, callback) == TraversalDecision::Break)
return TraversalDecision::Break;
}
return TraversalDecision::Continue;
}
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
Optional<HitTestResult> StackingContext::hit_test(CSSPixelPoint 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
{
LibJS+LibWeb: Wrap raw JS::Cell*/& fields in GCPtr/NonnullGCPtr
2023-02-26 16:09:02 -07:00
if (!m_box->is_visible())
LibWeb: Make hit testing respect hidden overflow
2022-07-03 18:34:51 -03:00
return {};
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 transform_origin = this->transform_origin().to_type<CSSPixels>();
// NOTE: This CSSPixels -> Float -> CSSPixels conversion is because we can't AffineTransform::map() a CSSPixelPoint.
Gfx::FloatPoint offset_position {
LibWeb+WebContent: Forbid access to underlying type of CSSPixels Although DistinctNumeric, which is supposed to abstract the underlying type, was used to represent CSSPixels, we have a whole bunch of places in the layout code that assume CSSPixels::value() returns a floating-point type. This assumption makes it difficult to replace the underlying type in CSSPixels with a non-floating type. To make it easier to transition CSSPixels to fixed-point math, one step we can take is to prevent access to the underlying type using value() and instead use explicit conversions with the to_float(), to_double(), and to_int() methods.
2023-06-12 21:37:35 +03:00
(position.x() - transform_origin.x()).to_float(),
(position.y() - transform_origin.y()).to_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: Fix hit testing for fixed position nodes Subtract the scroll offset translation from the position when checking for intersection between boxes within fixed position nodes.
2023-07-15 16:32:13 +02:00
if (paintable_box().layout_box().is_fixed_position()) {
auto scroll_offset = paintable_box().document().browsing_context()->viewport_scroll_offset();
transformed_position.translate_by(-scroll_offset);
}
LibWeb: Make hit testing respect hidden overflow
2022-07-03 18:34:51 -03:00
// FIXME: Support more overflow variations.
LibWeb/Painting: Rename StackingContext::paintable{ => _box}() It returns a PaintableBox, not any Paintable.
2023-04-20 16:00:21 +01:00
if (paintable_box().computed_values().overflow_x() == CSS::Overflow::Hidden && paintable_box().computed_values().overflow_y() == CSS::Overflow::Hidden) {
LibWeb+WebContent: Forbid access to underlying type of CSSPixels Although DistinctNumeric, which is supposed to abstract the underlying type, was used to represent CSSPixels, we have a whole bunch of places in the layout code that assume CSSPixels::value() returns a floating-point type. This assumption makes it difficult to replace the underlying type in CSSPixels with a non-floating type. To make it easier to transition CSSPixels to fixed-point math, one step we can take is to prevent access to the underlying type using value() and instead use explicit conversions with the to_float(), to_double(), and to_int() methods.
2023-06-12 21:37:35 +03:00
if (!paintable_box().absolute_border_box_rect().contains(transformed_position.x(), transformed_position.y()))
LibWeb: Make hit testing respect hidden overflow
2022-07-03 18:34:51 -03:00
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).
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];
LibJS+LibWeb: Wrap raw JS::Cell*/& fields in GCPtr/NonnullGCPtr
2023-02-26 16:09:02 -07:00
if (child.m_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: 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: Fix pointer-events check in hit_test
2022-10-20 01:43:31 +03:00
if (result.has_value() && result->paintable->visible_for_hit_testing())
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;
}
// 6. the child stacking contexts with stack level 0 and the positioned descendants with stack level 0.
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
Optional<HitTestResult> result;
LibWeb: Rename remaining paint_box variables to paintable_box These don't match the type name, which is confusing.
2023-04-20 16:02:16 +01:00
for_each_in_subtree_of_type_within_same_stacking_context_in_reverse<PaintableBox>(paintable_box(), [&](PaintableBox const& paintable_box) {
LibWeb: Make hit testing respect hidden overflow
2022-07-03 18:34:51 -03:00
// FIXME: Support more overflow variations.
LibWeb: Rename remaining paint_box variables to paintable_box These don't match the type name, which is confusing.
2023-04-20 16:02:16 +01:00
if (paintable_box.computed_values().overflow_x() == CSS::Overflow::Hidden && paintable_box.computed_values().overflow_y() == CSS::Overflow::Hidden) {
LibWeb+WebContent: Forbid access to underlying type of CSSPixels Although DistinctNumeric, which is supposed to abstract the underlying type, was used to represent CSSPixels, we have a whole bunch of places in the layout code that assume CSSPixels::value() returns a floating-point type. This assumption makes it difficult to replace the underlying type in CSSPixels with a non-floating type. To make it easier to transition CSSPixels to fixed-point math, one step we can take is to prevent access to the underlying type using value() and instead use explicit conversions with the to_float(), to_double(), and to_int() methods.
2023-06-12 21:37:35 +03:00
if (!paintable_box.absolute_border_box_rect().contains(transformed_position.x(), transformed_position.y()))
LibWeb: Make hit testing respect hidden overflow
2022-07-03 18:34:51 -03:00
return TraversalDecision::SkipChildrenAndContinue;
}
LibWeb: Rename remaining paint_box variables to paintable_box These don't match the type name, which is confusing.
2023-04-20 16:02:16 +01:00
auto const& z_index = paintable_box.computed_values().z_index();
auto& layout_box = paintable_box.layout_box();
if (z_index.value_or(0) == 0 && layout_box.is_positioned() && !paintable_box.stacking_context()) {
auto candidate = paintable_box.hit_test(transformed_position, type);
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
if (candidate.has_value() && candidate->paintable->visible_for_hit_testing()) {
result = move(candidate);
return TraversalDecision::Break;
}
}
LibWeb: Rename remaining paint_box variables to paintable_box These don't match the type name, which is confusing.
2023-04-20 16:02:16 +01:00
if (paintable_box.stacking_context()) {
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
if (z_index.value_or(0) == 0) {
LibWeb: Rename remaining paint_box variables to paintable_box These don't match the type name, which is confusing.
2023-04-20 16:02:16 +01:00
auto candidate = paintable_box.stacking_context()->hit_test(transformed_position, type);
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
if (candidate.has_value() && candidate->paintable->visible_for_hit_testing()) {
result = move(candidate);
return TraversalDecision::Break;
}
}
}
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 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
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.
LibJS+LibWeb: Wrap raw JS::Cell*/& fields in GCPtr/NonnullGCPtr
2023-02-26 16:09:02 -07:00
if (m_box->children_are_inline() && is<Layout::BlockContainer>(*m_box)) {
LibWeb/Painting: Rename StackingContext::paintable{ => _box}() It returns a PaintableBox, not any Paintable.
2023-04-20 16:00:21 +01:00
auto result = paintable_box().hit_test(transformed_position, type);
LibWeb: Fix pointer-events check in hit_test
2022-10-20 01:43:31 +03:00
if (result.has_value() && result->paintable->visible_for_hit_testing())
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: Rename remaining paint_box variables to paintable_box These don't match the type name, which is confusing.
2023-04-20 16:02:16 +01:00
for_each_in_subtree_of_type_within_same_stacking_context_in_reverse<PaintableBox>(paintable_box(), [&](PaintableBox const& paintable_box) {
LibWeb: Make hit testing respect hidden overflow
2022-07-03 18:34:51 -03:00
// FIXME: Support more overflow variations.
LibWeb: Rename remaining paint_box variables to paintable_box These don't match the type name, which is confusing.
2023-04-20 16:02:16 +01:00
if (paintable_box.computed_values().overflow_x() == CSS::Overflow::Hidden && paintable_box.computed_values().overflow_y() == CSS::Overflow::Hidden) {
LibWeb+WebContent: Forbid access to underlying type of CSSPixels Although DistinctNumeric, which is supposed to abstract the underlying type, was used to represent CSSPixels, we have a whole bunch of places in the layout code that assume CSSPixels::value() returns a floating-point type. This assumption makes it difficult to replace the underlying type in CSSPixels with a non-floating type. To make it easier to transition CSSPixels to fixed-point math, one step we can take is to prevent access to the underlying type using value() and instead use explicit conversions with the to_float(), to_double(), and to_int() methods.
2023-06-12 21:37:35 +03:00
if (!paintable_box.absolute_border_box_rect().contains(transformed_position.x(), transformed_position.y()))
LibWeb: Make hit testing respect hidden overflow
2022-07-03 18:34:51 -03:00
return TraversalDecision::SkipChildrenAndContinue;
}
LibWeb: Rename remaining paint_box variables to paintable_box These don't match the type name, which is confusing.
2023-04-20 16:02:16 +01:00
auto& layout_box = paintable_box.layout_box();
LibWeb: Use paint tree traversal helpers in StackingContext
2022-04-08 15:56:18 +02:00
if (layout_box.is_floating()) {
LibWeb: Rename remaining paint_box variables to paintable_box These don't match the type name, which is confusing.
2023-04-20 16:02:16 +01:00
if (auto candidate = paintable_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: 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: 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: Fix pointer-events check in hit_test
2022-10-20 01:43:31 +03:00
if (result.has_value() && result->paintable->visible_for_hit_testing())
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
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.
LibJS+LibWeb: Wrap raw JS::Cell*/& fields in GCPtr/NonnullGCPtr
2023-02-26 16:09:02 -07:00
if (!m_box->children_are_inline()) {
LibWeb: Rename remaining paint_box variables to paintable_box These don't match the type name, which is confusing.
2023-04-20 16:02:16 +01:00
for_each_in_subtree_of_type_within_same_stacking_context_in_reverse<PaintableBox>(paintable_box(), [&](PaintableBox const& paintable_box) {
LibWeb: Make hit testing respect hidden overflow
2022-07-03 18:34:51 -03:00
// FIXME: Support more overflow variations.
LibWeb: Rename remaining paint_box variables to paintable_box These don't match the type name, which is confusing.
2023-04-20 16:02:16 +01:00
if (paintable_box.computed_values().overflow_x() == CSS::Overflow::Hidden && paintable_box.computed_values().overflow_y() == CSS::Overflow::Hidden) {
LibWeb+WebContent: Forbid access to underlying type of CSSPixels Although DistinctNumeric, which is supposed to abstract the underlying type, was used to represent CSSPixels, we have a whole bunch of places in the layout code that assume CSSPixels::value() returns a floating-point type. This assumption makes it difficult to replace the underlying type in CSSPixels with a non-floating type. To make it easier to transition CSSPixels to fixed-point math, one step we can take is to prevent access to the underlying type using value() and instead use explicit conversions with the to_float(), to_double(), and to_int() methods.
2023-06-12 21:37:35 +03:00
if (!paintable_box.absolute_border_box_rect().contains(transformed_position.x(), transformed_position.y()))
LibWeb: Make hit testing respect hidden overflow
2022-07-03 18:34:51 -03:00
return TraversalDecision::SkipChildrenAndContinue;
}
LibWeb: Rename remaining paint_box variables to paintable_box These don't match the type name, which is confusing.
2023-04-20 16:02:16 +01:00
auto& layout_box = paintable_box.layout_box();
LibWeb: Use paint tree traversal helpers in StackingContext
2022-04-08 15:56:18 +02:00
if (!layout_box.is_absolutely_positioned() && !layout_box.is_floating()) {
LibWeb: Rename remaining paint_box variables to paintable_box These don't match the type name, which is confusing.
2023-04-20 16:02:16 +01:00
if (auto candidate = paintable_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: 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: 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: Fix pointer-events check in hit_test
2022-10-20 01:43:31 +03:00
if (result.has_value() && result->paintable->visible_for_hit_testing())
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).
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];
LibJS+LibWeb: Wrap raw JS::Cell*/& fields in GCPtr/NonnullGCPtr
2023-02-26 16:09:02 -07:00
if (child.m_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: 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: Fix pointer-events check in hit_test
2022-10-20 01:43:31 +03:00
if (result.has_value() && result->paintable->visible_for_hit_testing())
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+WebContent: Forbid access to underlying type of CSSPixels Although DistinctNumeric, which is supposed to abstract the underlying type, was used to represent CSSPixels, we have a whole bunch of places in the layout code that assume CSSPixels::value() returns a floating-point type. This assumption makes it difficult to replace the underlying type in CSSPixels with a non-floating type. To make it easier to transition CSSPixels to fixed-point math, one step we can take is to prevent access to the underlying type using value() and instead use explicit conversions with the to_float(), to_double(), and to_int() methods.
2023-06-12 21:37:35 +03:00
if (paintable_box().absolute_border_box_rect().contains(transformed_position.x(), transformed_position.y())) {
LibWeb: Move hit testing to the painting tree
2022-03-11 00:03:28 +01:00
return HitTestResult {
LibWeb/Painting: Rename StackingContext::paintable{ => _box}() It returns a PaintableBox, not any Paintable.
2023-04-20 16:00:21 +01:00
.paintable = const_cast<PaintableBox&>(paintable_box()),
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/Painting: Rename StackingContext::paintable{ => _box}() It returns a PaintableBox, not any Paintable.
2023-04-20 16:00:21 +01:00
builder.appendff("SC for {} {} [children: {}] (z-index: ", m_box->debug_description(), paintable_box().absolute_rect(), m_children.size());
LibJS+LibWeb: Wrap raw JS::Cell*/& fields in GCPtr/NonnullGCPtr
2023-02-26 16:09:02 -07:00
if (m_box->computed_values().z_index().has_value())
builder.appendff("{}", m_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