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

61 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
/*
* 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 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 {
public:
LibWeb: Make StackingContext point to paint tree instead of layout tree Eventually we should not need the layout tree for anything when painting and this code will only look at the paint tree. For now, this is just another step in that direction.
2023-08-19 15:20:45 +02:00
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: Make StackingContext point to paint tree instead of layout tree Eventually we should not need the layout tree for anything when painting and this code will only look at the paint tree. For now, this is just another step in that direction.
2023-08-19 15:20:45 +02:00
PaintableBox const& paintable_box() const { return *m_paintable_box; }
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: Treat grid item as it creates stacking context during painting Grid specification https://www.w3.org/TR/css-grid-2/#z-order defines special painting order for grid items which should be the same as for defined for inline-blocks in CSS2.
2023-08-20 19:42:54 +02:00
void paint_node_as_stacking_context(Paintable const&, PaintContext&) const;
LibWeb: Make StackingContext point to paint tree instead of layout tree Eventually we should not need the layout tree for anything when painting and this code will only look at the paint tree. For now, this is just another step in that direction.
2023-08-19 15:20:45 +02:00
void paint_descendants(PaintContext&, Paintable const&, StackingContextPaintPhase) const;
LibWeb: Make StackingContext paint functions const
2022-03-10 15:44:43 +01:00
void paint(PaintContext&) const;
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> hit_test(CSSPixelPoint, HitTestType) 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::FloatMatrix4x4 const& transform_matrix() const { return m_transform; }
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: 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: Make StackingContext point to paint tree instead of layout tree Eventually we should not need the layout tree for anything when painting and this code will only look at the paint tree. For now, this is just another step in that direction.
2023-08-19 15:20:45 +02:00
JS::NonnullGCPtr<PaintableBox> m_paintable_box;
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::FloatMatrix4x4 m_transform;
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 m_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
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: Draw elements with opacity in a separate stacking context
2021-07-23 13:19:16 +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 paint_child(PaintContext&, StackingContext const&) const;
LibWeb: Make StackingContext paint functions const
2022-03-10 15:44:43 +01:00
void paint_internal(PaintContext&) 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
Gfx::FloatMatrix4x4 get_transformation_matrix(CSS::Transformation const& transformation) const;
Gfx::FloatMatrix4x4 combine_transformations(Vector<CSS::Transformation> const& transformations) const;
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 transform_origin() const { return m_transform_origin; }
Gfx::FloatPoint compute_transform_origin() 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