Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-31 05:10:57 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/Layout/LayoutState.h

248 lines
11 KiB
C
Raw Normal View History

LibWeb: Add Layout::FormattingState The purpose of this new object will be to keep track of various states during an ongoing layout. Until now, we've been updating layout tree nodes as we go during layout, which adds an invisible layer of implicit serialization to the whole layout system. My idea with FormattingState is that running layout will produce a result entirely contained within the FormattingState object. At the end of layout, it can then be applied to the layout tree, or simply queried for some metrics we were trying to determine. When doing subtree layouts to determine intrinsic sizes, we will eventually be able to clone the current FormattingState, and run the subtree layout in isolation, opening up opportunities for parallelism. This first patch doesn't go very far though, it merely adds the object as a skeleton class, and makes sure the root BFC has one. :^)
2022-02-19 20:13:47 +01:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 13:19:50 +02:00
* Copyright (c) 2022, Andreas Kling <andreas@ladybird.org>
LibWeb: Add Layout::FormattingState The purpose of this new object will be to keep track of various states during an ongoing layout. Until now, we've been updating layout tree nodes as we go during layout, which adds an invisible layer of implicit serialization to the whole layout system. My idea with FormattingState is that running layout will produce a result entirely contained within the FormattingState object. At the end of layout, it can then be applied to the layout tree, or simply queried for some metrics we were trying to determine. When doing subtree layouts to determine intrinsic sizes, we will eventually be able to clone the current FormattingState, and run the subtree layout in isolation, opening up opportunities for parallelism. This first patch doesn't go very far though, it merely adds the object as a skeleton class, and makes sure the root BFC has one. :^)
2022-02-19 20:13:47 +01:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
#include <AK/HashMap.h>
LibWeb: Port painting to use the new Skia-backed Gfx::Path SVG and and CSS border rendering now sits on top of SkPath instead of the old Gfx::DeprecatedPath. Due to an imperceptible (255, 255, 255) vs (255, 254, 255) color diff in one ref test, I changed that test to not depend on border rendering for a positive result, since that was incidental.
2024-08-09 14:00:10 +02:00
#include <LibGfx/Path.h>
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
#include <LibGfx/Point.h>
LibWeb: Store overflow data in the FormattingState
2022-02-21 11:22:08 +01:00
#include <LibWeb/Layout/Box.h>
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
#include <LibWeb/Layout/LineBox.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: Layout SVG <text> elements during layout (not while painting) Previously, all SVG <text> elements were zero-sized boxes, that were only actually positioned and sized during painting. This led to a number of problems, the most visible of which being that text could not be scaled based on the viewBox. Which this patch, <text> elements get a correctly sized layout box, that can be hit-tested and respects the SVG viewBox. To share code with SVGGeometryElement's the PathData (from the prior commit) has been split into a computed path and computed transforms. The computed path is specific to geometry elements, but the computed transforms are shared between all SVG graphics elements.
2023-10-29 19:11:46 +00:00
#include <LibWeb/Painting/SVGGraphicsPaintable.h>
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
LibWeb: Add Layout::FormattingState The purpose of this new object will be to keep track of various states during an ongoing layout. Until now, we've been updating layout tree nodes as we go during layout, which adds an invisible layer of implicit serialization to the whole layout system. My idea with FormattingState is that running layout will produce a result entirely contained within the FormattingState object. At the end of layout, it can then be applied to the layout tree, or simply queried for some metrics we were trying to determine. When doing subtree layouts to determine intrinsic sizes, we will eventually be able to clone the current FormattingState, and run the subtree layout in isolation, opening up opportunities for parallelism. This first patch doesn't go very far though, it merely adds the object as a skeleton class, and makes sure the root BFC has one. :^)
2022-02-19 20:13:47 +01:00
namespace Web::Layout {
LibWeb: Express intrinsic size layout via size constraints Previously, we had three layout modes: - Normal: - Everything uses the computed values from CSS. - MinContent: - Containing blocks act as if they have 0 width. - All line breaking opportunities are taken. - MaxContent: - Containing blocks act as if they have infinite width. - Only forced line breaks are accepted. The above was based on a set of misunderstandings of CSS sizing. A major problem with the above was that *all* containing blocks behaved differently during intrinsic size layout, not just the relevant one. With this patch there are only two layout modes: - Normal: - Everything uses the computed values from CSS. - IntrinsicSizeDetermination: - One or more boxes have size constraints applied. There are two size constraints per layout box, set here: - FormattingState::NodeState::width_constraint - FormattingState::NodeState::height_constraint They are of type SizeConstraint and can be one of None, MinContent, or MaxContent. The default is None. When performing an IntrinsicSizeDetermination layout, we now assign a size constraint to the box we're trying to determine the intrinsic size of, which is then honored by using two new helpers to query the dimensions of containing blocks: - FormattingContext::containing_block_width_for(Box) - FormattingContext::containing_block_height_for(Box) If there's a relevant constraint in effect on the Box, the size of its containing block is adjusted accordingly. This is essentially an implementation of the "available space" constraints from CSS-SIZING-3. I'm sure some things will break from this, and we'll have to deal with that separately. Spec: https://drafts.csswg.org/css-sizing-3/#available
2022-07-09 15:17:47 +02:00
enum class SizeConstraint {
None,
MinContent,
MaxContent,
};
LibWeb: Reorganize layout algorithms around available space This is a big and messy change, and here's the gist: - AvaliableSpace is now 2x AvailableSize (width and height) - Layout algorithms are redesigned around the idea of available space - When doing layout across nested formatting contexts, the parent context tells the child context how much space is available for the child's root box in both axes. - "Available space" replaces "containing block width" in most places. - The width and height in a box's UsedValues are considered to be definite after they're assigned to. Marking something as having definite size is no longer a separate step, This probably introduces various regressions, but the big win here is that our layout system now works with available space, just like the specs are written. Fixing issues will be much easier going forward, since you don't need to do nearly as much conversion from "spec logic" to "LibWeb logic" as you previously did.
2022-09-27 15:29:17 +02:00
class AvailableSize;
class AvailableSpace;
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
// https://www.w3.org/TR/css-position-3/#static-position-rectangle
struct StaticPositionRect {
enum class Alignment {
Start,
Center,
End,
};
CSSPixelRect rect;
Alignment horizontal_alignment { Alignment::Start };
Alignment vertical_alignment { Alignment::Start };
CSSPixelPoint aligned_position_for_box_with_size(CSSPixelSize const& size) const
{
CSSPixelPoint position = rect.location();
if (horizontal_alignment == Alignment::Center)
position.set_x(position.x() + (rect.width() - size.width()) / 2);
else if (horizontal_alignment == Alignment::End)
position.set_x(position.x() + rect.width() - size.width());
if (vertical_alignment == Alignment::Center)
position.set_y(position.y() + (rect.height() - size.height()) / 2);
else if (vertical_alignment == Alignment::End)
position.set_y(position.y() + rect.height() - size.height());
return position;
}
};
LibWeb: Rename FormattingState to LayoutState This seems a bit more descriptive (and also a bit shorter).
2022-07-16 23:30:32 +02:00
struct LayoutState {
LayoutState()
LibWeb: Give FormattingState a reference to its root state FormattingStates can have parents, in case we're performing nested layouts to determine something's intrinsic size. In those cases, it will soon be useful to find the outermost (root) state.
2022-03-18 12:31:26 +01:00
: m_root(*this)
{
}
LibWeb: Make LayoutState use HashMap instead of potentially huge Vector Before this change, LayoutState essentially had a Vector<UsedValues*> resized to the exact number of layout nodes in the current document. When a nested layout is performed (to calculate the intrinsic size of something), we make a new LayoutState with its own Vector. If an entry is missing in a nested LayoutState, we check the parent chain all the way up to the root. Because each nested LayoutState had to allocate a new Vector with space for all layout nodes, this could get really nasty on very large pages (such as the ECMA262 specification). This patch replaces the Vector with a HashMap. There's now a small cost to lookups, but what we get in return is the ability to handle huge layout trees without spending eternity in page faults.
2023-05-23 07:47:37 +02:00
explicit LayoutState(LayoutState const* parent);
~LayoutState();
LibWeb: Give FormattingState a reference to its root state FormattingStates can have parents, in case we're performing nested layouts to determine something's intrinsic size. In those cases, it will soon be useful to find the outermost (root) state.
2022-03-18 12:31:26 +01:00
LibWeb: Rename FormattingState to LayoutState This seems a bit more descriptive (and also a bit shorter).
2022-07-16 23:30:32 +02:00
LayoutState const& find_root() const
LibWeb: Make Layout::FormattingState copies shallow Previously, each NodeState in a FormattingState was shared with the parent FormattingState, but the HashMap of NodeState had to be copied when making FormattingState copies. This patch makes copying instant by keeping a pointer to the parent FormattingState instead. When fetching immutable state via get(), we may now return a reference to a NodeState owned by a parent FormattingState. get_mutable() will copy any NodeState found in the ancestor chain before making a brand new one.
2022-03-12 16:33:11 +01:00
{
LibWeb: Rename FormattingState to LayoutState This seems a bit more descriptive (and also a bit shorter).
2022-07-16 23:30:32 +02:00
LayoutState const* root = this;
LibWeb: Give FormattingState a reference to its root state FormattingStates can have parents, in case we're performing nested layouts to determine something's intrinsic size. In those cases, it will soon be useful to find the outermost (root) state.
2022-03-18 12:31:26 +01:00
for (auto* state = m_parent; state; state = state->m_parent)
root = state;
return *root;
LibWeb: Make Layout::FormattingState copies shallow Previously, each NodeState in a FormattingState was shared with the parent FormattingState, but the HashMap of NodeState had to be copied when making FormattingState copies. This patch makes copying instant by keeping a pointer to the parent FormattingState instead. When fetching immutable state via get(), we may now return a reference to a NodeState owned by a parent FormattingState. get_mutable() will copy any NodeState found in the ancestor chain before making a brand new one.
2022-03-12 16:33:11 +01:00
}
LibWeb: Rename LayoutState::NodeState => LayoutState::UsedValues This object contains all the CSS "used values" as seen during the layout process, so calling it "used values" seems appropriate. :^)
2022-07-16 23:43:48 +02:00
struct UsedValues {
LibWeb: Relax restrictions on LayoutState::get() input type Instead of only letting NodeWithStyleAndBoxModelMetrics (and subclasses) have used values in the layout state, we now allow any NodeWithStyle.
2023-09-04 12:24:48 +02:00
NodeWithStyle const& node() const { return *m_node; }
void set_node(NodeWithStyle&, UsedValues const* containing_block_used_values);
LibWeb: Stop putting the FormattingState nodes in a slow hash map Instead, put them in a Vector<OwnPtr<NodeState>>. Each layout node has a unique index into the vector. It's a simple serial ID assigned during layout tree construction. Every new layout restarts the sequence at 0 for the next ICB. This is a huge layout speed improvement on all content.
2022-07-11 17:12:58 +02:00
LibWeb: Give UsedValues a pointer to containing block UsedValues This will allow us to skip hash lookups when traversing the containing block chain and looking at everyone's UsedValues.
2024-01-17 11:23:33 +01:00
UsedValues const* containing_block_used_values() const { return m_containing_block_used_values; }
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels content_width() const { return m_content_width; }
CSSPixels content_height() const { return m_content_height; }
void set_content_width(CSSPixels);
void set_content_height(CSSPixels);
LibWeb: Add accessors for UsedValues::computed_{width,height} This is preparation for doing some more work when assigning to these values.
2022-07-17 17:59:02 +02:00
LibWeb: Make box content sizes indefinite before intrinsic sizing When calculating the intrinsic width of a box, we now make its content width & height indefinite before entering the intrinsic sizing layout. This ensures that any geometry assigned to the box by its parent formatting context is ignored. For intrinsic heights, we only make the content height indefinite. This is because used content width is a valid (but optional) input to intrinsic height calculation.
2023-03-27 14:12:05 +02:00
void set_indefinite_content_width();
void set_indefinite_content_height();
LibWeb: Add UsedValues::set_has_definite_width/height() These will be used to explicitly mark some box geometry as definite at various stages of layout. It's gonna get finicky.
2024-01-29 15:35:02 +01:00
void set_has_definite_width(bool has_definite_width) { m_has_definite_width = has_definite_width; }
void set_has_definite_height(bool has_definite_height) { m_has_definite_height = has_definite_height; }
LibWeb: Assign hypothetical flex item main sizes as temporary main size This colors a bit outside the lines of the specification, but the spec doesn't offer a proper explanation for how descendants of a flex item are supposed to have access to the flex item's main size for purposes of percentage resolution. The approach I came up with here was to take the hypothetical main size of each flex item, and assign it as a temporary main size. This allows percentage resolution in descendants to work against the pre-flexing main size of items. This seems to match how other engines behave, although it feels somewhat dirty. If/when we learn more about this, we can come up with something nicer.
2022-10-15 09:26:30 +02:00
// NOTE: These are used by FlexFormattingContext to assign a temporary main size to items
// early on, so that descendants have something to resolve percentages against.
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
void set_temporary_content_width(CSSPixels);
void set_temporary_content_height(CSSPixels);
LibWeb: Assign hypothetical flex item main sizes as temporary main size This colors a bit outside the lines of the specification, but the spec doesn't offer a proper explanation for how descendants of a flex item are supposed to have access to the flex item's main size for purposes of percentage resolution. The approach I came up with here was to take the hypothetical main size of each flex item, and assign it as a temporary main size. This allows percentage resolution in descendants to work against the pre-flexing main size of items. This seems to match how other engines behave, although it feels somewhat dirty. If/when we learn more about this, we can come up with something nicer.
2022-10-15 09:26:30 +02:00
LibWeb: Move "has-definite-width/height" flags to UsedValues This state is less static than we originally assumed, and there are special formatting context-specific rules that say certain sizes are definite in special circumstances. To be able to support this, we move the has-definite-size flags from the layout node to the UsedValues struct instead.
2022-07-17 18:46:38 +02:00
bool has_definite_width() const { return m_has_definite_width && width_constraint == SizeConstraint::None; }
bool has_definite_height() const { return m_has_definite_height && height_constraint == SizeConstraint::None; }
LibWeb: Reorganize layout algorithms around available space This is a big and messy change, and here's the gist: - AvaliableSpace is now 2x AvailableSize (width and height) - Layout algorithms are redesigned around the idea of available space - When doing layout across nested formatting contexts, the parent context tells the child context how much space is available for the child's root box in both axes. - "Available space" replaces "containing block width" in most places. - The width and height in a box's UsedValues are considered to be definite after they're assigned to. Marking something as having definite size is no longer a separate step, This probably introduces various regressions, but the big win here is that our layout system now works with available space, just like the specs are written. Fixing issues will be much easier going forward, since you don't need to do nearly as much conversion from "spec logic" to "LibWeb logic" as you previously did.
2022-09-27 15:29:17 +02:00
// Returns the available space for content inside this layout box.
// If the space in an axis is indefinite, and the outer space is an intrinsic sizing constraint,
// the constraint is used in that axis instead.
AvailableSpace available_inner_space_or_constraints_from(AvailableSpace const& outer_space) const;
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
void set_content_offset(CSSPixelPoint);
void set_content_x(CSSPixels);
void set_content_y(CSSPixels);
LibWeb: Move "has-definite-width/height" flags to UsedValues This state is less static than we originally assumed, and there are special formatting context-specific rules that say certain sizes are definite in special circumstances. To be able to support this, we move the has-definite-size flags from the layout node to the UsedValues struct instead.
2022-07-17 18:46:38 +02:00
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixelPoint offset;
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
LibWeb: Express intrinsic size layout via size constraints Previously, we had three layout modes: - Normal: - Everything uses the computed values from CSS. - MinContent: - Containing blocks act as if they have 0 width. - All line breaking opportunities are taken. - MaxContent: - Containing blocks act as if they have infinite width. - Only forced line breaks are accepted. The above was based on a set of misunderstandings of CSS sizing. A major problem with the above was that *all* containing blocks behaved differently during intrinsic size layout, not just the relevant one. With this patch there are only two layout modes: - Normal: - Everything uses the computed values from CSS. - IntrinsicSizeDetermination: - One or more boxes have size constraints applied. There are two size constraints per layout box, set here: - FormattingState::NodeState::width_constraint - FormattingState::NodeState::height_constraint They are of type SizeConstraint and can be one of None, MinContent, or MaxContent. The default is None. When performing an IntrinsicSizeDetermination layout, we now assign a size constraint to the box we're trying to determine the intrinsic size of, which is then honored by using two new helpers to query the dimensions of containing blocks: - FormattingContext::containing_block_width_for(Box) - FormattingContext::containing_block_height_for(Box) If there's a relevant constraint in effect on the Box, the size of its containing block is adjusted accordingly. This is essentially an implementation of the "available space" constraints from CSS-SIZING-3. I'm sure some things will break from this, and we'll have to deal with that separately. Spec: https://drafts.csswg.org/css-sizing-3/#available
2022-07-09 15:17:47 +02:00
SizeConstraint width_constraint { SizeConstraint::None };
SizeConstraint height_constraint { SizeConstraint::None };
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels margin_left { 0 };
CSSPixels margin_right { 0 };
CSSPixels margin_top { 0 };
CSSPixels margin_bottom { 0 };
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels border_left { 0 };
CSSPixels border_right { 0 };
CSSPixels border_top { 0 };
CSSPixels border_bottom { 0 };
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels padding_left { 0 };
CSSPixels padding_right { 0 };
CSSPixels padding_top { 0 };
CSSPixels padding_bottom { 0 };
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels inset_left { 0 };
CSSPixels inset_right { 0 };
CSSPixels inset_top { 0 };
CSSPixels inset_bottom { 0 };
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
Vector<LineBox> line_boxes;
LibWeb: Adjust border widths for tables using collapsing borders When using the collapsing border model, cells on either side of the edge get half the specified width of the border for their box model.
2023-07-07 05:31:54 +00:00
CSSPixels margin_box_left() const { return margin_left + border_left_collapsed() + padding_left; }
CSSPixels margin_box_right() const { return margin_right + border_right_collapsed() + padding_right; }
CSSPixels margin_box_top() const { return margin_top + border_top_collapsed() + padding_top; }
CSSPixels margin_box_bottom() const { return margin_bottom + border_bottom_collapsed() + padding_bottom; }
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels margin_box_width() const { return margin_box_left() + content_width() + margin_box_right(); }
CSSPixels margin_box_height() const { return margin_box_top() + content_height() + margin_box_bottom(); }
LibWeb: Add margin box helpers to Layout::FormattingState
2022-03-24 18:06:45 +01:00
LibWeb: Adjust border widths for tables using collapsing borders When using the collapsing border model, cells on either side of the edge get half the specified width of the border for their box model.
2023-07-07 05:31:54 +00:00
CSSPixels border_box_left() const { return border_left_collapsed() + padding_left; }
CSSPixels border_box_right() const { return border_right_collapsed() + padding_right; }
CSSPixels border_box_top() const { return border_top_collapsed() + padding_top; }
CSSPixels border_box_bottom() const { return border_bottom_collapsed() + padding_bottom; }
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels border_box_width() const { return border_box_left() + content_width() + border_box_right(); }
CSSPixels border_box_height() const { return border_box_top() + content_height() + border_box_bottom(); }
LibWeb: Store overflow data in the FormattingState
2022-02-21 11:22:08 +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
Optional<LineBoxFragmentCoordinate> containing_line_box_fragment;
LibWeb: Add accessors for UsedValues::computed_{width,height} This is preparation for doing some more work when assigning to these values.
2022-07-17 17:59:02 +02:00
LibWeb: Include all floating descendants in BFC root's automatic height Before this change, we were only considering floating boxes that were immediate children of the BFC root.
2022-09-09 23:56:55 +02:00
void add_floating_descendant(Box const& box) { m_floating_descendants.set(&box); }
auto const& floating_descendants() const { return m_floating_descendants; }
LibWeb: Complete table border conflict resolution Add the element type and grid position to the algorithm and change the table borders painting to apply the new criteria to corners as well.
2023-07-12 04:20:37 +00:00
void set_override_borders_data(Painting::PaintableBox::BordersDataWithElementKind const& override_borders_data) { m_override_borders_data = override_borders_data; }
LibWeb: Add partial implementation of border conflict resolution Fix handling of border style specified per column as well.
2023-06-04 14:21:20 +00:00
auto const& override_borders_data() const { return m_override_borders_data; }
LibWeb: Store table cell indices and spans in PaintableBox The adjacency information is required to position borders correctly between columns and rows.
2023-07-01 02:58:11 +00:00
void set_table_cell_coordinates(Painting::PaintableBox::TableCellCoordinates const& table_cell_coordinates) { m_table_cell_coordinates = table_cell_coordinates; }
auto const& table_cell_coordinates() const { return m_table_cell_coordinates; }
LibWeb: Port painting to use the new Skia-backed Gfx::Path SVG and and CSS border rendering now sits on top of SkPath instead of the old Gfx::DeprecatedPath. Due to an imperceptible (255, 255, 255) vs (255, 254, 255) color diff in one ref test, I changed that test to not depend on border rendering for a positive result, since that was incidental.
2024-08-09 14:00:10 +02:00
void set_computed_svg_path(Gfx::Path const& svg_path) { m_computed_svg_path = svg_path; }
LibWeb: Layout SVG <text> elements during layout (not while painting) Previously, all SVG <text> elements were zero-sized boxes, that were only actually positioned and sized during painting. This led to a number of problems, the most visible of which being that text could not be scaled based on the viewBox. Which this patch, <text> elements get a correctly sized layout box, that can be hit-tested and respects the SVG viewBox. To share code with SVGGeometryElement's the PathData (from the prior commit) has been split into a computed path and computed transforms. The computed path is specific to geometry elements, but the computed transforms are shared between all SVG graphics elements.
2023-10-29 19:11:46 +00:00
auto& computed_svg_path() { return m_computed_svg_path; }
void set_computed_svg_transforms(Painting::SVGGraphicsPaintable::ComputedTransforms const& computed_transforms) { m_computed_svg_transforms = computed_transforms; }
auto const& computed_svg_transforms() const { return m_computed_svg_transforms; }
LibWeb: Store computed SVG path data/transforms in LayoutState This removes the awkward hack to recompute the layout transform at paint time, and makes it possible for path sizes to be computed during layout. For example, it's possible to use relative units in SVG shapes (e.g. <rect>), which can be resolved during layout, but would be hard to resolve again during painting.
2023-10-29 17:08:35 +00:00
LibWeb: Return used values for grid tracks in getComputedStyle() That's awkward, but getComputedStyle needs to return used track values for gridTemplateColumns and gridTemplateRows properties. This change implements it by saving style values with used values into layout state, so it could be assigned to paintables during LayoutState::commit() and later accessed by style_value_for_property(). I haven't seen it used in the wild, but WPT grid tests extensively use it. For example this change helps to go from 0/10 to 8/10 on this test: https://wpt.live/css/css-grid/layout-algorithm/grid-fit-content-percentage.html
2024-09-09 12:15:49 +02:00
void set_grid_template_columns(RefPtr<CSS::GridTrackSizeListStyleValue> used_values_for_grid_template_columns) { m_grid_template_columns = move(used_values_for_grid_template_columns); }
auto const& grid_template_columns() const { return m_grid_template_columns; }
void set_grid_template_rows(RefPtr<CSS::GridTrackSizeListStyleValue> used_values_for_grid_template_rows) { m_grid_template_rows = move(used_values_for_grid_template_rows); }
auto const& grid_template_rows() const { return m_grid_template_rows; }
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
void set_static_position_rect(StaticPositionRect const& static_position_rect) { m_static_position_rect = static_position_rect; }
CSSPixelPoint static_position() const
{
CSSPixelSize size;
size.set_width(content_width() + padding_left + padding_right + border_left + border_right + margin_left + margin_right);
size.set_height(content_height() + padding_top + padding_bottom + border_top + border_bottom + margin_top + margin_bottom);
return m_static_position_rect->aligned_position_for_box_with_size(size);
}
LibWeb: Add accessors for UsedValues::computed_{width,height} This is preparation for doing some more work when assigning to these values.
2022-07-17 17:59:02 +02:00
private:
LibWeb: Reorganize layout algorithms around available space This is a big and messy change, and here's the gist: - AvaliableSpace is now 2x AvailableSize (width and height) - Layout algorithms are redesigned around the idea of available space - When doing layout across nested formatting contexts, the parent context tells the child context how much space is available for the child's root box in both axes. - "Available space" replaces "containing block width" in most places. - The width and height in a box's UsedValues are considered to be definite after they're assigned to. Marking something as having definite size is no longer a separate step, This probably introduces various regressions, but the big win here is that our layout system now works with available space, just like the specs are written. Fixing issues will be much easier going forward, since you don't need to do nearly as much conversion from "spec logic" to "LibWeb logic" as you previously did.
2022-09-27 15:29:17 +02:00
AvailableSize available_width_inside() const;
AvailableSize available_height_inside() const;
LibWeb: Adjust border widths for tables using collapsing borders When using the collapsing border model, cells on either side of the edge get half the specified width of the border for their box model.
2023-07-07 05:31:54 +00:00
bool use_collapsing_borders_model() const { return m_override_borders_data.has_value(); }
// Implement the collapsing border model https://www.w3.org/TR/CSS22/tables.html#collapsing-borders.
CSSPixels border_left_collapsed() const { return use_collapsing_borders_model() ? round(border_left / 2) : border_left; }
CSSPixels border_right_collapsed() const { return use_collapsing_borders_model() ? round(border_right / 2) : border_right; }
CSSPixels border_top_collapsed() const { return use_collapsing_borders_model() ? round(border_top / 2) : border_top; }
CSSPixels border_bottom_collapsed() const { return use_collapsing_borders_model() ? round(border_bottom / 2) : border_bottom; }
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::Ptr<Layout::NodeWithStyle> m_node { nullptr };
LibWeb: Give UsedValues a pointer to containing block UsedValues This will allow us to skip hash lookups when traversing the containing block chain and looking at everyone's UsedValues.
2024-01-17 11:23:33 +01:00
UsedValues const* m_containing_block_used_values { nullptr };
LibWeb: Move "has-definite-width/height" flags to UsedValues This state is less static than we originally assumed, and there are special formatting context-specific rules that say certain sizes are definite in special circumstances. To be able to support this, we move the has-definite-size flags from the layout node to the UsedValues struct instead.
2022-07-17 18:46:38 +02:00
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels m_content_width { 0 };
CSSPixels m_content_height { 0 };
LibWeb: Move "has-definite-width/height" flags to UsedValues This state is less static than we originally assumed, and there are special formatting context-specific rules that say certain sizes are definite in special circumstances. To be able to support this, we move the has-definite-size flags from the layout node to the UsedValues struct instead.
2022-07-17 18:46:38 +02:00
bool m_has_definite_width { false };
bool m_has_definite_height { false };
LibWeb: Include all floating descendants in BFC root's automatic height Before this change, we were only considering floating boxes that were immediate children of the BFC root.
2022-09-09 23:56:55 +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
HashTable<GC::Ptr<Box const>> m_floating_descendants;
LibWeb: Add partial implementation of border conflict resolution Fix handling of border style specified per column as well.
2023-06-04 14:21:20 +00:00
LibWeb: Complete table border conflict resolution Add the element type and grid position to the algorithm and change the table borders painting to apply the new criteria to corners as well.
2023-07-12 04:20:37 +00:00
Optional<Painting::PaintableBox::BordersDataWithElementKind> m_override_borders_data;
LibWeb: Store table cell indices and spans in PaintableBox The adjacency information is required to position borders correctly between columns and rows.
2023-07-01 02:58:11 +00:00
Optional<Painting::PaintableBox::TableCellCoordinates> m_table_cell_coordinates;
LibWeb: Store computed SVG path data/transforms in LayoutState This removes the awkward hack to recompute the layout transform at paint time, and makes it possible for path sizes to be computed during layout. For example, it's possible to use relative units in SVG shapes (e.g. <rect>), which can be resolved during layout, but would be hard to resolve again during painting.
2023-10-29 17:08:35 +00:00
LibWeb: Port painting to use the new Skia-backed Gfx::Path SVG and and CSS border rendering now sits on top of SkPath instead of the old Gfx::DeprecatedPath. Due to an imperceptible (255, 255, 255) vs (255, 254, 255) color diff in one ref test, I changed that test to not depend on border rendering for a positive result, since that was incidental.
2024-08-09 14:00:10 +02:00
Optional<Gfx::Path> m_computed_svg_path;
LibWeb: Layout SVG <text> elements during layout (not while painting) Previously, all SVG <text> elements were zero-sized boxes, that were only actually positioned and sized during painting. This led to a number of problems, the most visible of which being that text could not be scaled based on the viewBox. Which this patch, <text> elements get a correctly sized layout box, that can be hit-tested and respects the SVG viewBox. To share code with SVGGeometryElement's the PathData (from the prior commit) has been split into a computed path and computed transforms. The computed path is specific to geometry elements, but the computed transforms are shared between all SVG graphics elements.
2023-10-29 19:11:46 +00:00
Optional<Painting::SVGGraphicsPaintable::ComputedTransforms> m_computed_svg_transforms;
LibWeb: Return used values for grid tracks in getComputedStyle() That's awkward, but getComputedStyle needs to return used track values for gridTemplateColumns and gridTemplateRows properties. This change implements it by saving style values with used values into layout state, so it could be assigned to paintables during LayoutState::commit() and later accessed by style_value_for_property(). I haven't seen it used in the wild, but WPT grid tests extensively use it. For example this change helps to go from 0/10 to 8/10 on this test: https://wpt.live/css/css-grid/layout-algorithm/grid-fit-content-percentage.html
2024-09-09 12:15:49 +02:00
RefPtr<CSS::GridTrackSizeListStyleValue> m_grid_template_columns;
RefPtr<CSS::GridTrackSizeListStyleValue> m_grid_template_rows;
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
Optional<StaticPositionRect> m_static_position_rect;
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
};
LibWeb: Make the paint tree a proper standalone tree Until now, paint trees have been piggybacking on the layout tree for traversal, and paintables didn't actually have their own parent/child pointers. This patch changes that by making Paintable inherit from TreeNode, and adding a new pass to LayoutState::commit() where we recursively build the new paint tree.
2023-08-18 12:30:27 +02:00
// Commits the used values produced by layout and builds a paintable tree.
void commit(Box& root);
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
LibWeb: Rename LayoutState::NodeState => LayoutState::UsedValues This object contains all the CSS "used values" as seen during the layout process, so calling it "used values" seems appropriate. :^)
2022-07-16 23:43:48 +02:00
// NOTE: get_mutable() will CoW the UsedValues if it's inherited from an ancestor state;
LibWeb: Relax restrictions on LayoutState::get() input type Instead of only letting NodeWithStyleAndBoxModelMetrics (and subclasses) have used values in the layout state, we now allow any NodeWithStyle.
2023-09-04 12:24:48 +02:00
UsedValues& get_mutable(NodeWithStyle const&);
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
LibWeb: Rename LayoutState::NodeState => LayoutState::UsedValues This object contains all the CSS "used values" as seen during the layout process, so calling it "used values" seems appropriate. :^)
2022-07-16 23:43:48 +02:00
// NOTE: get() will not CoW the UsedValues.
LibWeb: Relax restrictions on LayoutState::get() input type Instead of only letting NodeWithStyleAndBoxModelMetrics (and subclasses) have used values in the layout state, we now allow any NodeWithStyle.
2023-09-04 12:24:48 +02:00
UsedValues const& get(NodeWithStyle const&) const;
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +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
HashMap<GC::Ref<Layout::Node const>, NonnullOwnPtr<UsedValues>> used_values_per_layout_node;
LibWeb: Add functions for calculating intrinsic sizes of a Layout::Box FormattingContext can now calculate the intrinsic sizes (min-content and max-content in both axes) for a given Layout::Box. This is a rather expensive operation, as it necessitates performing two throwaway layouts of the subtree rooted at the box. Fortunately, we can cache the results of these calculations, as intrinsic sizes don't change based on other context around the box. They are intrinsic after all. :^)
2022-03-12 14:36:59 +01:00
// We cache intrinsic sizes once determined, as they will not change over the course of a full layout.
// This avoids computing them several times while performing flex layout.
struct IntrinsicSizes {
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
Optional<CSSPixels> min_content_width;
Optional<CSSPixels> max_content_width;
LibWeb: Split intrinsic heights cache based on available width Now that intrinsic heights (correctly) depend on the amount of available width, we can't just cache the first calculated min-content and max-content heights and reuse it without thinking. Instead, we have to cache three pairs: - min-content & max-content height with definite available width - min-content & max-content height with min-content available width - min-content & max-content height with max-content available width There might be some more elegant way of solving this, but basically this makes the cache work correctly when someone's containing block is being sized under a width constraint.
2022-10-08 20:27:54 +02:00
LibWeb: Forbid usage of indefinite width in calculate_min{max}_height Changing `calculate_min_content_heigh()` and `calculate_min_content_heigh()` to accept width as `CSSPixels`, instead of `AvailableSize` that might be indefinite, makes it more explicit that width is supposed to be known by the time height is measured. This change has a bit of collateral damage which is rows height calculation regression in `table/inline-table-width` that worked before by accident.
2023-08-12 15:17:17 +02:00
HashMap<CSSPixels, Optional<CSSPixels>> min_content_height;
HashMap<CSSPixels, Optional<CSSPixels>> max_content_height;
LibWeb: Add functions for calculating intrinsic sizes of a Layout::Box FormattingContext can now calculate the intrinsic sizes (min-content and max-content in both axes) for a given Layout::Box. This is a rather expensive operation, as it necessitates performing two throwaway layouts of the subtree rooted at the box. Fortunately, we can cache the results of these calculations, as intrinsic sizes don't change based on other context around the box. They are intrinsic after all. :^)
2022-03-12 14:36:59 +01:00
};
LibWeb: Only perform the requested form of intrinsic size calculation Before, querying any of the four intrinsic sizes would cause us to calculate all of them (the four being min-content width/height, and max-content width/height). Now, the helper functions only calculate the specific intrinsic size requested. It's then cached at the root formatting context level, so that it's never calculated twice within the same layout pass.
2022-07-08 12:44:49 +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
HashMap<GC::Ptr<NodeWithStyle const>, NonnullOwnPtr<IntrinsicSizes>> mutable intrinsic_sizes;
LibWeb: Make Layout::FormattingState copies shallow Previously, each NodeState in a FormattingState was shared with the parent FormattingState, but the HashMap of NodeState had to be copied when making FormattingState copies. This patch makes copying instant by keeping a pointer to the parent FormattingState instead. When fetching immutable state via get(), we may now return a reference to a NodeState owned by a parent FormattingState. get_mutable() will copy any NodeState found in the ancestor chain before making a brand new one.
2022-03-12 16:33:11 +01:00
LibWeb: Rename FormattingState to LayoutState This seems a bit more descriptive (and also a bit shorter).
2022-07-16 23:30:32 +02:00
LayoutState const* m_parent { nullptr };
LayoutState const& m_root;
LibWeb: Resolve relative offsets *once* after layout Instead of applying relative offsets (like position:relative insets) during painting and hit testing, we now do a pass at the end of layout and assign the final resolved offsets to paintables. This makes painting and hit testing easier since they don't have to think about relative offsets, and it also fixes a bug where offsets were not applied to text fragments inside inline-flow elements that were themselves position:relative.
2023-08-15 15:11:10 +02:00
private:
LibWeb: Resolve relpos fragment offsets only for inline paintables Prior to this change, we iterated through all fragments within each PaintableWithLines to resolve the relative position offset. This happened before transferring the fragments to their corresponding inline paintables. With this change, we significantly reduce amount of work by attempting to resolve relative position offsets only for those contained within inline paintables. Performance improvement on https://html.spec.whatwg.org/
2024-01-18 14:03:30 +01:00
void resolve_relative_positions();
LibWeb: Add Layout::FormattingState The purpose of this new object will be to keep track of various states during an ongoing layout. Until now, we've been updating layout tree nodes as we go during layout, which adds an invisible layer of implicit serialization to the whole layout system. My idea with FormattingState is that running layout will produce a result entirely contained within the FormattingState object. At the end of layout, it can then be applied to the layout tree, or simply queried for some metrics we were trying to determine. When doing subtree layouts to determine intrinsic sizes, we will eventually be able to clone the current FormattingState, and run the subtree layout in isolation, opening up opportunities for parallelism. This first patch doesn't go very far though, it merely adds the object as a skeleton class, and makes sure the root BFC has one. :^)
2022-02-19 20:13:47 +01:00
};
}
Reference in a new issue Copy permalink