mirrors/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-01-24 02:03:06 -05:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/Layout/Box.h

75 lines
2.6 KiB
C
Raw Normal View History

Meta: Add license header to source files As suggested by Joshua, this commit adds the 2-clause BSD license as a comment block to the top of every source file. For the first pass, I've just added myself for simplicity. I encourage everyone to add themselves as copyright holders of any file they've added or modified in some significant way. If I've added myself in error somewhere, feel free to replace it with the appropriate copyright holder instead. Going forward, all new source files should include a license header.
2020-01-18 09:38:21 +01:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 13:19:50 +02:00
* Copyright (c) 2018-2022, Andreas Kling <andreas@ladybird.org>
Meta: Add license header to source files As suggested by Joshua, this commit adds the 2-clause BSD license as a comment block to the top of every source file. For the first pass, I've just added myself for simplicity. I encourage everyone to add themselves as copyright holders of any file they've added or modified in some significant way. If I've added myself in error somewhere, feel free to replace it with the appropriate copyright holder instead. Going forward, all new source files should include a license header.
2020-01-18 09:38:21 +01: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
Meta: Add license header to source files As suggested by Joshua, this commit adds the 2-clause BSD license as a comment block to the top of every source file. For the first pass, I've just added myself for simplicity. I encourage everyone to add themselves as copyright holders of any file they've added or modified in some significant way. If I've added myself in error somewhere, feel free to replace it with the appropriate copyright holder instead. Going forward, all new source files should include a license header.
2020-01-18 09:38:21 +01:00
*/
LibHTML: Introduce LayoutBox and LayoutNodeWithStyleAndBoxModelMetrics To streamline the layout tree and remove irrelevant data from classes that don't need it, this patch adds two new LayoutNode subclasses. LayoutNodeWithStyleAndBoxModelMetrics should be inherited by any layout node that cares about box model metrics (margin, border, and padding.) LayoutBox should be inherited by any layout node that can have a rect. This makes LayoutText significantly smaller (from 140 to 40 bytes) and clarifies a lot of things about the layout tree. I'm also adding next_sibling() and previous_sibling() overloads to LayoutBlock that return a LayoutBlock*. This is okay since blocks only ever have block siblings. Do also note that the semantics of is<T> slightly change in this patch: is<T>(nullptr) now returns true, to facilitate allowing to<T>(nullptr).
2019-10-15 16:48:38 +02:00
#pragma once
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/OwnPtr.h>
LibGfx: Templatize Point, Size, and Rect
2020-07-25 21:31:47 -07:00
#include <LibGfx/Rect.h>
LibJS+LibWeb: Move headers around to allow including Value from Cell The goal here is to allow Cell::initialize to return a ThrowCompletion, to handle OOM for example. Cell.h will then need to include Completion.h which must include Value.h. This currently can't happen because Value.h includes BigInt.h, which in turn includes Cell.h. So we would have an include cycle. This removes BigInt.h from Value.h, as it is forward-declarable (it is only referred to with a reference or pointer). Then the Value overload for Cell::Visitor::visit is moved to Cell.h, and missing BigInt.h includes as peppered as needed.
2023-01-28 11:26:03 -05:00
#include <LibJS/Heap/Cell.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/Node.h>
LibHTML: Introduce LayoutBox and LayoutNodeWithStyleAndBoxModelMetrics To streamline the layout tree and remove irrelevant data from classes that don't need it, this patch adds two new LayoutNode subclasses. LayoutNodeWithStyleAndBoxModelMetrics should be inherited by any layout node that cares about box model metrics (margin, border, and padding.) LayoutBox should be inherited by any layout node that can have a rect. This makes LayoutText significantly smaller (from 140 to 40 bytes) and clarifies a lot of things about the layout tree. I'm also adding next_sibling() and previous_sibling() overloads to LayoutBlock that return a LayoutBlock*. This is okay since blocks only ever have block siblings. Do also note that the semantics of is<T> slightly change in this patch: is<T>(nullptr) now returns true, to facilitate allowing to<T>(nullptr).
2019-10-15 16:48:38 +02:00
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
namespace Web::Layout {
LibWeb: Move everything into the Web namespace
2020-03-07 10:27:02 +01:00
LibWeb: Store box's containing line box fragment in FormattingState Layout should not change any properties of a box until the moment a FormattingState is committed.
2022-02-28 12:41:23 +01:00
struct LineBoxFragmentCoordinate {
size_t line_box_index { 0 };
size_t fragment_index { 0 };
};
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
class Box : public NodeWithStyleAndBoxModelMetrics {
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC_CELL(Box, NodeWithStyleAndBoxModelMetrics);
LibWeb: Make the layout tree GC-allocated This removes a set of complex reference cycles between DOM, layout tree and browsing context. It also makes lifetimes much easier to reason about, as the DOM and layout trees are now free to keep each other alive.
2022-10-17 14:41:50 +02:00
LibHTML: Introduce LayoutBox and LayoutNodeWithStyleAndBoxModelMetrics To streamline the layout tree and remove irrelevant data from classes that don't need it, this patch adds two new LayoutNode subclasses. LayoutNodeWithStyleAndBoxModelMetrics should be inherited by any layout node that cares about box model metrics (margin, border, and padding.) LayoutBox should be inherited by any layout node that can have a rect. This makes LayoutText significantly smaller (from 140 to 40 bytes) and clarifies a lot of things about the layout tree. I'm also adding next_sibling() and previous_sibling() overloads to LayoutBlock that return a LayoutBlock*. This is okay since blocks only ever have block siblings. Do also note that the semantics of is<T> slightly change in this patch: is<T>(nullptr) now returns true, to facilitate allowing to<T>(nullptr).
2019-10-15 16:48:38 +02:00
public:
LibWeb/Layout: Rename Box::{paint => paintable}_box() It returns a PaintableBox, not a 'PaintBox'.
2023-04-20 16:00:42 +01:00
Painting::PaintableBox const* paintable_box() const;
LibWeb: Add non-const version of paintable_box() in Layout::Node Allows to remove a bunch of const_cast's
2023-08-07 00:51:05 +02:00
Painting::PaintableBox* paintable_box();
LibWeb: Rework the layout engine to use relative offsets The box tree and line boxes now all store a relative offset from their containing block, instead of an absolute (document-relative) position. This removes a huge pain point from the layout system which was having to adjust offsets recursively when something moved. It also makes some layout logic significantly simpler. Every box can still find its absolute position by walking its chain of containing blocks and accumulating the translation from the root. This is currently what we do both for rendering and hit testing.
2020-06-10 10:42:29 +02:00
LibWeb: Move "natural size" concept into Layout::Box Having this here instead of in ReplacedBox means we can access it when figuring out what the "preferred aspect ratio" is. There's some inconsistency between specs about what this is called, but they're moving towards referring to this as "natural width/height/ aspect-ratio", so let's copy that terminology.
2023-06-08 15:56:28 +01:00
// https://www.w3.org/TR/css-images-3/#natural-dimensions
Optional<CSSPixels> natural_width() const { return m_natural_width; }
Optional<CSSPixels> natural_height() const { return m_natural_height; }
LibWeb: Use `CSSPixelFraction` to represent aspect ratios This allows us to retain perfect precision for aspect ratios derived from either the intrinsic sizes of replaced elements, or the `aspect-ratio` CSS property.
2023-09-03 17:33:58 -05:00
Optional<CSSPixelFraction> natural_aspect_ratio() const { return m_natural_aspect_ratio; }
LibWeb: Make intrinsic width/height/ratio a Box concept and simplify it Apparently it's not only replaced elements that can have intrinsic sizes, so let's move this concept from ReplacedBox to Box. To avoid bloating Box, we make the accessors virtual.
2021-10-14 18:37:24 +02:00
LibWeb: Move "natural size" concept into Layout::Box Having this here instead of in ReplacedBox means we can access it when figuring out what the "preferred aspect ratio" is. There's some inconsistency between specs about what this is called, but they're moving towards referring to this as "natural width/height/ aspect-ratio", so let's copy that terminology.
2023-06-08 15:56:28 +01:00
bool has_natural_width() const { return natural_width().has_value(); }
bool has_natural_height() const { return natural_height().has_value(); }
bool has_natural_aspect_ratio() const { return natural_aspect_ratio().has_value(); }
void set_natural_width(Optional<CSSPixels> width) { m_natural_width = width; }
void set_natural_height(Optional<CSSPixels> height) { m_natural_height = height; }
LibWeb: Use `CSSPixelFraction` to represent aspect ratios This allows us to retain perfect precision for aspect ratios derived from either the intrinsic sizes of replaced elements, or the `aspect-ratio` CSS property.
2023-09-03 17:33:58 -05:00
void set_natural_aspect_ratio(Optional<CSSPixelFraction> ratio) { m_natural_aspect_ratio = ratio; }
LibWeb: Make intrinsic width/height/ratio a Box concept and simplify it Apparently it's not only replaced elements that can have intrinsic sizes, so let's move this concept from ReplacedBox to Box. To avoid bloating Box, we make the accessors virtual.
2021-10-14 18:37:24 +02:00
LibWeb: Obey CSS aspect-ratio property during layout Calculate a "preferred aspect ratio" based on the value of `aspect-ratio` and the presence of a natural aspect ratio, and use that in layout. This is by no means complete or perfect, but we do now apply the given aspect-ratio to things. The spec is a bit vague, just saying to calculate sizes for aspect-ratio'ed boxes the same as you would for replaced elements. My naive solution here is to find everywhere we were checking for a ReplacedBox, and then also accept a regular Box with a preferred aspect ratio. This gets us pretty far. :^) https://www.w3.org/TR/css-sizing-4/#aspect-ratio-minimum is not at all implemented.
2023-06-08 16:47:50 +01:00
// https://www.w3.org/TR/css-sizing-4/#preferred-aspect-ratio
LibWeb: Use `CSSPixelFraction` to represent aspect ratios This allows us to retain perfect precision for aspect ratios derived from either the intrinsic sizes of replaced elements, or the `aspect-ratio` CSS property.
2023-09-03 17:33:58 -05:00
Optional<CSSPixelFraction> preferred_aspect_ratio() const;
LibWeb: Obey CSS aspect-ratio property during layout Calculate a "preferred aspect ratio" based on the value of `aspect-ratio` and the presence of a natural aspect ratio, and use that in layout. This is by no means complete or perfect, but we do now apply the given aspect-ratio to things. The spec is a bit vague, just saying to calculate sizes for aspect-ratio'ed boxes the same as you would for replaced elements. My naive solution here is to find everywhere we were checking for a ReplacedBox, and then also accept a regular Box with a preferred aspect ratio. This gets us pretty far. :^) https://www.w3.org/TR/css-sizing-4/#aspect-ratio-minimum is not at all implemented.
2023-06-08 16:47:50 +01:00
bool has_preferred_aspect_ratio() const { return preferred_aspect_ratio().has_value(); }
LibWeb: Add Painting::Box and move things from Layout::Box into it The "paintable" state in Layout::Box was actually not safe to access until after layout had been performed. As a first step towards making this harder to mess up accidentally, this patch moves painting information from Layout::Box to a new class: Painting::Box. Every layout can have a corresponding paint box, and it holds the final used metrics determined by layout. The paint box is created and populated by FormattingState::commit(). I've also added DOM::Node::paint_box() as a convenient way to access the paint box (if available) of a given DOM node. Going forward, I believe this will allow us to better separate data that belongs to layout vs painting, and also open up opportunities for naturally invalidating caches in the paint box (since it's reconstituted by every layout.)
2022-03-09 23:53:41 +01:00
virtual ~Box() override;
LibWeb: Remove specified style from layout nodes Layout nodes now only carry CSS computer values with them. The main idea here is to give them only what they need to perform layout, and leave the rest back in the DOM.
2021-01-06 14:10:53 +01:00
LibWeb: Fix iframes flickering on window resize After finishing layout, iframe layout boxes (FrameBox) get notified about their new size by LayoutState::commit(). This information is forwarded to the nested browsing context, where it can be used for layout of the nested document. The problem here was that we notified the FrameBox twice. Once when assigning the used offset to its paintable, and once when assigning its size. Because the offset was assigned first, we ended up telling the FrameBox "btw, your size is 0x0". This caused us to throw away all the layout information we had for the nested document. We'd then say "actually, your size is 300x200" (or something) but by then it was already too late, and we had to do a full relayout. This caused iframes to flicker as every time their containing document was laid out, we'd nuke the iframe layout and redo it (on a zero timer). The fix is pleasantly simple: we didn't need to inform the nested document of its offset in the containing document's layout anyway. Only its size is relevant. So we can simply remove the first call, which removes the bogus 0x0 temporary size. Note that iframes may still flicker if they change size in the containing document. That's a separate issue that will require more finesse to solve. However, this fixes a very noticeable common case.
2023-05-15 12:06:40 +02:00
virtual void did_set_content_size() { }
LibWeb: Start implementing proper layout of replaced elements LayoutReplaced now has intrinsic width, height and ratio. Only some of the values may be present. The layout algorithm takes the various configurations into account per the CSS specification. This is still pretty immature but at least we're moving forward. :^)
2020-06-05 19:13:27 +02:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
virtual GC::Ptr<Painting::Paintable> create_paintable() const override;
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
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
void add_contained_abspos_child(GC::Ref<Node> child) { m_contained_abspos_children.append(child); }
LibWeb: Reset a vector of contained abspos before collecting them again Fixes a bug when a vector with contained absolutely positioned boxes keeps growing, resulting in more duplicated work on each subsequent layout.
2024-09-13 16:35:31 +02:00
void clear_contained_abspos_children() { m_contained_abspos_children.clear(); }
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
Vector<GC::Ref<Node>> const& contained_abspos_children() const { return m_contained_abspos_children; }
LibWeb: Make FC of containing block responsible for abspos layout Before this change, a formatting context was responsible for layout of absolutely positioned boxes whose FC root box was their parent (either directly or indirectly). This only worked correctly when the containing block of the absolutely positioned child did not escape the FC root. This is because the width and height of an absolutely positioned box are resolved based on the size of its containing block, so we needed to ensure that the containing block's layout was completed before laying out an absolutely positioned box. With this change, the layout of absolutely positioned boxes is delayed until the FC responsible for the containing block's layout is complete. This has affected the way we calculate the static position. It is no longer possible to ask the FC for a box's static position, as this FC's state might be gone by the time the layout for absolutely positioned elements occurs. Instead, the "static position rectangle" (a concept from the spec) is saved in the layout state, along with information on how to align the box within this rectangle when its width and height are resolved.
2024-09-10 19:02:03 +02:00
virtual void visit_edges(Cell::Visitor&) override;
LibWeb: Add Painting::Box and move things from Layout::Box into it The "paintable" state in Layout::Box was actually not safe to access until after layout had been performed. As a first step towards making this harder to mess up accidentally, this patch moves painting information from Layout::Box to a new class: Painting::Box. Every layout can have a corresponding paint box, and it holds the final used metrics determined by layout. The paint box is created and populated by FormattingState::commit(). I've also added DOM::Node::paint_box() as a convenient way to access the paint box (if available) of a given DOM node. Going forward, I believe this will allow us to better separate data that belongs to layout vs painting, and also open up opportunities for naturally invalidating caches in the paint box (since it's reconstituted by every layout.)
2022-03-09 23:53:41 +01:00
protected:
LibWeb: Remove reference counting for `CSS::StyleProperties` `AK::CopyOnWrite` already does reference counting, so there is no need to do it again.
2024-10-26 17:42:27 +02:00
Box(DOM::Document&, DOM::Node*, CSS::StyleProperties);
LibWeb: Allocate CSS::ComputedValues objects on the heap This makes them cheap to move around, since we can store them in a NonnullOwnPtr instead of memcopying 2584(!) bytes. Drastically reduces the chance of stack overflow while building the layout tree for deeply nested DOMs (since tree building was putting these things on the stack). This change also exposed a completely unnecessary ComputedValues deep copy in block layout.
2024-01-27 08:38:27 +01:00
Box(DOM::Document&, DOM::Node*, NonnullOwnPtr<CSS::ComputedValues>);
LibWeb: Add Painting::Box and move things from Layout::Box into it The "paintable" state in Layout::Box was actually not safe to access until after layout had been performed. As a first step towards making this harder to mess up accidentally, this patch moves painting information from Layout::Box to a new class: Painting::Box. Every layout can have a corresponding paint box, and it holds the final used metrics determined by layout. The paint box is created and populated by FormattingState::commit(). I've also added DOM::Node::paint_box() as a convenient way to access the paint box (if available) of a given DOM node. Going forward, I believe this will allow us to better separate data that belongs to layout vs painting, and also open up opportunities for naturally invalidating caches in the paint box (since it's reconstituted by every layout.)
2022-03-09 23:53:41 +01:00
LibHTML: Introduce LayoutBox and LayoutNodeWithStyleAndBoxModelMetrics To streamline the layout tree and remove irrelevant data from classes that don't need it, this patch adds two new LayoutNode subclasses. LayoutNodeWithStyleAndBoxModelMetrics should be inherited by any layout node that cares about box model metrics (margin, border, and padding.) LayoutBox should be inherited by any layout node that can have a rect. This makes LayoutText significantly smaller (from 140 to 40 bytes) and clarifies a lot of things about the layout tree. I'm also adding next_sibling() and previous_sibling() overloads to LayoutBlock that return a LayoutBlock*. This is okay since blocks only ever have block siblings. Do also note that the semantics of is<T> slightly change in this patch: is<T>(nullptr) now returns true, to facilitate allowing to<T>(nullptr).
2019-10-15 16:48:38 +02:00
private:
LibWeb: Specialize is<DOM::Element>() and is<Layout::Box>() These two show up in profiles, so let's add specializations for them.
2021-01-07 17:31:26 +01:00
virtual bool is_box() const final { return true; }
LibWeb: Move scroll state from Layout::BlockContainer to Layout::Box Let's allow any box to be scrollable, not just block containers.
2023-01-23 17:04:24 +01:00
LibWeb: Move "natural size" concept into Layout::Box Having this here instead of in ReplacedBox means we can access it when figuring out what the "preferred aspect ratio" is. There's some inconsistency between specs about what this is called, but they're moving towards referring to this as "natural width/height/ aspect-ratio", so let's copy that terminology.
2023-06-08 15:56:28 +01:00
Optional<CSSPixels> m_natural_width;
Optional<CSSPixels> m_natural_height;
LibWeb: Use `CSSPixelFraction` to represent aspect ratios This allows us to retain perfect precision for aspect ratios derived from either the intrinsic sizes of replaced elements, or the `aspect-ratio` CSS property.
2023-09-03 17:33:58 -05:00
Optional<CSSPixelFraction> m_natural_aspect_ratio;
LibWeb: Make FC of containing block responsible for abspos layout Before this change, a formatting context was responsible for layout of absolutely positioned boxes whose FC root box was their parent (either directly or indirectly). This only worked correctly when the containing block of the absolutely positioned child did not escape the FC root. This is because the width and height of an absolutely positioned box are resolved based on the size of its containing block, so we needed to ensure that the containing block's layout was completed before laying out an absolutely positioned box. With this change, the layout of absolutely positioned boxes is delayed until the FC responsible for the containing block's layout is complete. This has affected the way we calculate the static position. It is no longer possible to ask the FC for a box's static position, as this FC's state might be gone by the time the layout for absolutely positioned elements occurs. Instead, the "static position rectangle" (a concept from the spec) is saved in the layout state, along with information on how to align the box within this rectangle when its width and height are resolved.
2024-09-10 19:02:03 +02:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
Vector<GC::Ref<Node>> m_contained_abspos_children;
LibHTML: Introduce LayoutBox and LayoutNodeWithStyleAndBoxModelMetrics To streamline the layout tree and remove irrelevant data from classes that don't need it, this patch adds two new LayoutNode subclasses. LayoutNodeWithStyleAndBoxModelMetrics should be inherited by any layout node that cares about box model metrics (margin, border, and padding.) LayoutBox should be inherited by any layout node that can have a rect. This makes LayoutText significantly smaller (from 140 to 40 bytes) and clarifies a lot of things about the layout tree. I'm also adding next_sibling() and previous_sibling() overloads to LayoutBlock that return a LayoutBlock*. This is okay since blocks only ever have block siblings. Do also note that the semantics of is<T> slightly change in this patch: is<T>(nullptr) now returns true, to facilitate allowing to<T>(nullptr).
2019-10-15 16:48:38 +02:00
};
LibWeb: Specialize is<DOM::Element>() and is<Layout::Box>() These two show up in profiles, so let's add specializations for them.
2021-01-07 17:31:26 +01:00
template<>
LibWeb: Add fast_is<T>() for some DOM and layout node subclasses The generic is<T>() uses dynamic_cast which is fine in the majority of cases, but when one of them shows up in profiles, we can make it faster by answering the is-a question manually.
2021-01-17 09:34:01 +01:00
inline bool Node::fast_is<Box>() const { return is_box(); }
LibWeb: Specialize is<DOM::Element>() and is<Layout::Box>() These two show up in profiles, so let's add specializations for them.
2021-01-07 17:31:26 +01:00
}
Reference in a new issue Copy permalink