LadybirdBrowser/ladybird
1
1
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-09-20 01:37:39 +03:00
Code Issues Packages Projects Releases Wiki Activity
b4b947c607
ladybird/Userland/Libraries/LibWeb/Painting/StackingContext.h

66 lines
2.1 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 18:29:35 +03:00
/*
* Copyright (c) 2020, Andreas Kling <kling@serenityos.org>
*
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 11:24:48 +03: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 18:29:35 +03:00
*/
#pragma once
#include <AK/Vector.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 03:29:20 +03:00
#include <LibGfx/Matrix4x4.h>
LibWeb: Allow inline nodes to establish a stacking context With this change, a stacking context can be established by any paintable, including inline paintables. The stacking context traversal is updated to remove the assumption that the stacking context root is paintable box.
2024-01-03 04:40:31 +03:00
#include <LibWeb/Painting/InlinePaintable.h>
LibWeb: Move hit testing to the painting tree
2022-03-11 02:03:28 +03:00
#include <LibWeb/Painting/Paintable.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 18:29:35 +03:00
LibWeb: Move StackingContext and PaintPhase into the Painting namespace
2022-03-10 04:13:28 +03: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 18:29:35 +03:00
class StackingContext {
LibWeb: Reduce paintable tree traversals during hit-testing By storing a list of positioned and floating descendants within the stacking context tree node, we can eliminate the need for costly paintable tree traversals during hit-testing. This optimization results in hit-testing being 2 to 2.5 times faster on https://ziglang.org/documentation/master/
2024-03-01 13:54:44 +03:00
friend class ViewportPaintable;
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 18:29:35 +03:00
public:
LibWeb: Allow inline nodes to establish a stacking context With this change, a stacking context can be established by any paintable, including inline paintables. The stacking context traversal is updated to remove the assumption that the stacking context root is paintable box.
2024-01-03 04:40:31 +03:00
StackingContext(Paintable&, 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 18:29:35 +03:00
StackingContext* parent() { return m_parent; }
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
StackingContext const* parent() const { return 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 18:29:35 +03:00
LibWeb: Allow inline nodes to establish a stacking context With this change, a stacking context can be established by any paintable, including inline paintables. The stacking context traversal is updated to remove the assumption that the stacking context root is paintable box.
2024-01-03 04:40:31 +03:00
Paintable const& paintable() const { return *m_paintable; }
PaintableBox const& paintable_box() const { return verify_cast<PaintableBox>(*m_paintable); }
InlinePaintable const& inline_paintable() const { return verify_cast<InlinePaintable>(*m_paintable); }
LibWeb: Use paint tree traversal helpers in StackingContext
2022-04-08 16:56:18 +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
enum class StackingContextPaintPhase {
BackgroundAndBorders,
Floats,
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 18:39:45 +03:00
BackgroundAndBordersForInlineLevelAndReplaced,
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
Foreground,
FocusAndOverlay,
};
LibWeb: Make StackingContext functions `static` where possible These don't need to be member functions, and this will make it easier to use these to paint <mask> elements (into an off-screen mask bitmap).
2023-09-10 15:41:00 +03:00
static void paint_node_as_stacking_context(Paintable const&, PaintContext&);
static void paint_descendants(PaintContext&, Paintable const&, StackingContextPaintPhase);
LibWeb: Make StackingContext paint functions const
2022-03-10 17:44:43 +03:00
void paint(PaintContext&) const;
LibWeb: Change StackingContext::hit_test() to accept callback This change modifies hit_test() to no longer return the first paintable encountered at a specified position. Instead, this function accepts a callback that is invoked for each paintable located at a position, in hit-testing order. This modification will allow us to reuse this call for `Document.elementsFromPoint()` in upcoming changes.
2024-02-13 23:34:07 +03:00
[[nodiscard]] TraversalDecision hit_test(CSSPixelPoint, HitTestType, Function<TraversalDecision(HitTestResult)> const& callback) const;
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 18:29:35 +03: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 17:18:20 +03:00
Gfx::AffineTransform affine_transform_matrix() const;
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 18:29:35 +03:00
void dump(int indent = 0) const;
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 18:19:54 +03:00
void sort();
LibWeb: Verify in runtime that stacking context is not painted twice Duplicated stacking context painting is easy to introduce because of a bit complicated traversal order and very painful to debug.
2024-04-29 18:33:50 +03:00
void set_last_paint_generation_id(u64 generation_id);
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 18:29:35 +03:00
private:
LibWeb: Allow inline nodes to establish a stacking context With this change, a stacking context can be established by any paintable, including inline paintables. The stacking context traversal is updated to remove the assumption that the stacking context root is paintable box.
2024-01-03 04:40:31 +03:00
JS::NonnullGCPtr<Paintable> m_paintable;
LibWeb: Respect CSS z-index property while painting To support z-ordering when painting, the layout tree now has a parallel sparse tree of stacking contexts. The rules for which layout boxes establish a stacking context are a bit complex, but the intent is to encapsulate the decision making into establishes_stacking_context(). When we paint, we start from the ICB (LayoutDocument) who always has a StackingContext and then paint the tree of StackingContexts where each node has its children sorted by z-index. This is pretty crude, but gets the basic job done. Note that this does not yet support hit testing; hit testing is still done using a naive treewalk from the root.
2020-06-15 18:29:35 +03:00
StackingContext* const m_parent { nullptr };
Vector<StackingContext*> m_children;
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 13:01:14 +03:00
size_t m_index_in_tree_order { 0 };
LibWeb: Verify in runtime that stacking context is not painted twice Duplicated stacking context painting is easy to introduce because of a bit complicated traversal order and very painful to debug.
2024-04-29 18:33:50 +03:00
Optional<u64> m_last_paint_generation_id;
LibWeb: Draw elements with opacity in a separate stacking context
2021-07-23 13:19:16 +03:00
LibWeb: Fix some GCVerifier warnings
2024-04-05 23:47:48 +03:00
Vector<JS::NonnullGCPtr<Paintable const>> m_positioned_descendants_with_stack_level_0_and_stacking_contexts;
Vector<JS::NonnullGCPtr<Paintable const>> m_non_positioned_floating_descendants;
LibWeb: Reduce paintable tree traversals during hit-testing By storing a list of positioned and floating descendants within the stacking context tree node, we can eliminate the need for costly paintable tree traversals during hit-testing. This optimization results in hit-testing being 2 to 2.5 times faster on https://ziglang.org/documentation/master/
2024-03-01 13:54:44 +03:00
LibWeb: Make StackingContext functions `static` where possible These don't need to be member functions, and this will make it easier to use these to paint <mask> elements (into an off-screen mask bitmap).
2023-09-10 15:41:00 +03:00
static void paint_child(PaintContext&, StackingContext const&);
LibWeb: Make StackingContext paint functions const
2022-03-10 17:44:43 +03:00
void paint_internal(PaintContext&) const;
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 18:29:35 +03:00
};
}
Reference in New Issue Copy Permalink