Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-05 07:40:58 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/Painting/StackingContext.h

64 lines
1.9 KiB
C
Raw Normal View History

LibWeb: Respect CSS z-index property while painting To support z-ordering when painting, the layout tree now has a parallel sparse tree of stacking contexts. The rules for which layout boxes establish a stacking context are a bit complex, but the intent is to encapsulate the decision making into establishes_stacking_context(). When we paint, we start from the ICB (LayoutDocument) who always has a StackingContext and then paint the tree of StackingContexts where each node has its children sorted by z-index. This is pretty crude, but gets the basic job done. Note that this does not yet support hit testing; hit testing is still done using a naive treewalk from the root.
2020-06-15 17:29:35 +02:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 13:19:50 +02:00
* Copyright (c) 2020, Andreas Kling <andreas@ladybird.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
*/
#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 01:29:20 +01:00
#include <LibGfx/Matrix4x4.h>
LibWeb: Move hit testing to the painting tree
2022-03-11 00:03:28 +01: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 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
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 11:54:44 +01: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 17:29:35 +02:00
public:
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
StackingContext(PaintableBox&, 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
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 17:29:35 +02:00
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
PaintableBox const& paintable_box() const { return *m_paintable; }
LibWeb: Use paint tree traversal helpers in StackingContext
2022-04-08 15:56:18 +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
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 16:39:45 +01: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 13:41:00 +01:00
static void paint_node_as_stacking_context(Paintable const&, PaintContext&);
static void paint_descendants(PaintContext&, Paintable const&, StackingContextPaintPhase);
LibWeb: Don't allow SVG boxes to create a stacking context Prior to this change, SVGs were following the CSS painting order, which means SVG boxes could have established stacking context and be sorted by z-index. There is a section in the spec that defines what kind of SVG boxes should create a stacking context https://www.w3.org/TR/SVG2/render.html#EstablishingStackingContex Although this spec is marked as a draft and rendering order described in this spec does not match what other engines do. This spec issue comment has a good summary of what other engines actually do regarding painting order https://github.com/w3c/svgwg/issues/264#issuecomment-246432360 "as long as you're relying solely on the default z-index (which SVG1 does, by definition), nothing ever changes order when you apply opacity/filter/etc". This change aligns our implementation with other engines by forbidding SVGs to create a formatting context and painting them in order they are defined in tree tree.
2024-10-09 02:57:57 +02:00
static void paint_svg(PaintContext&, PaintableBox const&, PaintPhase);
LibWeb: Make StackingContext paint functions const
2022-03-10 15:44:43 +01: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 21:34:07 +01: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 17:29:35 +02: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
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 17:29:35 +02: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 16:19:54 +01: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 17:33:50 +02: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 17:29:35 +02:00
private:
LibWeb: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
GC::Ref<PaintableBox> 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 17:29:35 +02: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 12:01:14 +02: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 17:33:50 +02: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: Allow stacking context to only be created by PaintableBox For a while we used the wider Paintable type for stacking context, because it was allowed to be created by InlinePaintable and PaintableBox. Now, when InlinePaintable type is gone, we can use more specific PaintableBox type for a stacking context.
2024-11-18 16:05:22 +01:00
Vector<GC::Ref<PaintableBox const>> m_positioned_descendants_and_stacking_contexts_with_stack_level_0;
Vector<GC::Ref<PaintableBox 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 11:54:44 +01:00
LibWeb: Make StackingContext functions `static` where possible These don't need to be member functions, and this will make it easier to use these to paint <mask> elements (into an off-screen mask bitmap).
2023-09-10 13:41:00 +01:00
static void paint_child(PaintContext&, StackingContext const&);
LibWeb: Make StackingContext paint functions const
2022-03-10 15:44:43 +01: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 17:29:35 +02:00
};
}
Reference in a new issue Copy permalink