Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-19 23:53:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibWeb/Layout/LayoutState.cpp

718 lines
34 KiB
C++
Raw Normal View History

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: Put debug spam about negative content sizes behind a flag We already clamp these values to zero, so it's actually pretty harmless when this happens. If someone wants to investigate these issues deeper and see if they can be fixed earlier in the layout pipeline, they can enable the spam locally.
2023-05-31 11:47:26 +02:00
* Copyright (c) 2022-2023, Andreas Kling <kling@serenityos.org>
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
*
* SPDX-License-Identifier: BSD-2-Clause
*/
LibWeb: Put debug spam about negative content sizes behind a flag We already clamp these values to zero, so it's actually pretty harmless when this happens. If someone wants to investigate these issues deeper and see if they can be fixed earlier in the layout pipeline, they can enable the spam locally.
2023-05-31 11:47:26 +02:00
#include <AK/Debug.h>
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
#include <LibWeb/Layout/AvailableSpace.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/BlockContainer.h>
LibWeb: Rename FormattingState to LayoutState This seems a bit more descriptive (and also a bit shorter).
2022-07-16 23:30:32 +02:00
#include <LibWeb/Layout/LayoutState.h>
LibWeb: Bring measuring of scrollable overflow closer to spec Importantly, we now only consider overflow from descendants with explicltly visible overflow, and only from descendants that have the measured box as their containing block. Also, we now measure scrollable overflow for all boxes, not just scroll containers. This will allow us to fix a long-standing paint problem in the next commit.
2023-07-12 18:55:23 +02:00
#include <LibWeb/Layout/Viewport.h>
LibWeb: Resolve border radius during layout and save it in paintables This change fixes a problem that we should not call `to_px()` to resolve any length or percentage values during paintables traversal because that is supposed to happen while performing layout. Also it improves performance because before we were resolving border radii during each painting phase but now it happens only once during layout.
2023-12-07 06:16:17 +01:00
#include <LibWeb/Painting/InlinePaintable.h>
LibWeb: Support transforms, stroking, gradients, etc for SVG <text> This makes use of the new Gfx::Path::text() to handle SVG text elements, with this text is just a regular path, and can be manipulated like any other graphics element. This removes the SVGTextPaintable and makes both <text> and geometry elements use a new (shared) SVGPathPaintable. This is identical to the old SVGGeometryPaintable. This simplifies painting as once something is resolved to a Gfx::Path, the painting logic is the same.
2023-11-04 21:31:35 +00:00
#include <LibWeb/Painting/SVGPathPaintable.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
namespace Web::Layout {
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
LayoutState::LayoutState(LayoutState const* parent)
: m_parent(parent)
, m_root(find_root())
{
}
LayoutState::~LayoutState()
{
}
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
LayoutState::UsedValues& LayoutState::get_mutable(NodeWithStyle const& node)
LibWeb: Use copy-on-write to make cloning a FormattingState much cheaper Instead of making a full copy of every NodeState when cloning a FormattingState, we make NodeState ref-counted and implement a basic copy-on-write mechanism. FormattingState::get_mutable() now makes a deep copy of the NodeState when first accessed *if* it is shared with other FormattingStates.
2022-02-28 12:32:23 +01:00
{
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
if (auto* used_values = used_values_per_layout_node.get(&node).value_or(nullptr))
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
return *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
for (auto const* ancestor = m_parent; ancestor; ancestor = ancestor->m_parent) {
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
if (auto* ancestor_used_values = ancestor->used_values_per_layout_node.get(&node).value_or(nullptr)) {
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
auto cow_used_values = adopt_own(*new UsedValues(*ancestor_used_values));
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
auto* cow_used_values_ptr = cow_used_values.ptr();
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
used_values_per_layout_node.set(&node, move(cow_used_values));
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
return *cow_used_values_ptr;
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: 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: 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: 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
auto const* containing_block_used_values = node.is_viewport() ? nullptr : &get(*node.containing_block());
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: 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
auto new_used_values = adopt_own(*new UsedValues);
auto* new_used_values_ptr = new_used_values.ptr();
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
new_used_values->set_node(const_cast<NodeWithStyle&>(node), containing_block_used_values);
used_values_per_layout_node.set(&node, move(new_used_values));
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
return *new_used_values_ptr;
LibWeb: Use copy-on-write to make cloning a FormattingState much cheaper Instead of making a full copy of every NodeState when cloning a FormattingState, we make NodeState ref-counted and implement a basic copy-on-write mechanism. FormattingState::get_mutable() now makes a deep copy of the NodeState when first accessed *if* it is shared with other FormattingStates.
2022-02-28 12:32:23 +01:00
}
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
LayoutState::UsedValues const& LayoutState::get(NodeWithStyle const& node) const
LibWeb: Use copy-on-write to make cloning a FormattingState much cheaper Instead of making a full copy of every NodeState when cloning a FormattingState, we make NodeState ref-counted and implement a basic copy-on-write mechanism. FormattingState::get_mutable() now makes a deep copy of the NodeState when first accessed *if* it is shared with other FormattingStates.
2022-02-28 12:32:23 +01:00
{
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
if (auto const* used_values = used_values_per_layout_node.get(&node).value_or(nullptr))
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
return *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: 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
for (auto const* ancestor = m_parent; ancestor; ancestor = ancestor->m_parent) {
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
if (auto const* ancestor_used_values = ancestor->used_values_per_layout_node.get(&node).value_or(nullptr))
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
return *ancestor_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: 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: 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
auto const* containing_block_used_values = node.is_viewport() ? nullptr : &get(*node.containing_block());
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: 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
auto new_used_values = adopt_own(*new UsedValues);
auto* new_used_values_ptr = new_used_values.ptr();
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
new_used_values->set_node(const_cast<NodeWithStyle&>(node), containing_block_used_values);
const_cast<LayoutState*>(this)->used_values_per_layout_node.set(&node, move(new_used_values));
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
return *new_used_values_ptr;
LibWeb: Use copy-on-write to make cloning a FormattingState much cheaper Instead of making a full copy of every NodeState when cloning a FormattingState, we make NodeState ref-counted and implement a basic copy-on-write mechanism. FormattingState::get_mutable() now makes a deep copy of the NodeState when first accessed *if* it is shared with other FormattingStates.
2022-02-28 12:32:23 +01:00
}
LibWeb: Bring measuring of scrollable overflow closer to spec Importantly, we now only consider overflow from descendants with explicltly visible overflow, and only from descendants that have the measured box as their containing block. Also, we now measure scrollable overflow for all boxes, not just scroll containers. This will allow us to fix a long-standing paint problem in the next commit.
2023-07-12 18:55:23 +02:00
// https://www.w3.org/TR/css-overflow-3/#scrollable-overflow
static CSSPixelRect measure_scrollable_overflow(Box const& box)
LibWeb: Measure the overflow for all scroll containers Instead of just measuring the layout viewport, we now measure overflow in every box that is a scroll container. This has the side effect of no longer creating paintables for layout boxes that didn't participate in layout. (For example, empty/anonymous boxes that were ignored by flex itemization.) Such boxes are now marked as "(not painted)" in the layout tree dumps, as they have no paintable to dump geometry from.
2023-05-29 08:53:39 +02:00
{
LibWeb: Bring measuring of scrollable overflow closer to spec Importantly, we now only consider overflow from descendants with explicltly visible overflow, and only from descendants that have the measured box as their containing block. Also, we now measure scrollable overflow for all boxes, not just scroll containers. This will allow us to fix a long-standing paint problem in the next commit.
2023-07-12 18:55:23 +02:00
if (!box.paintable_box())
return {};
auto& paintable_box = const_cast<Painting::PaintableBox&>(*box.paintable_box());
if (paintable_box.scrollable_overflow_rect().has_value())
return paintable_box.scrollable_overflow_rect().value();
// The scrollable overflow area is the union of:
// - The scroll container’s own padding box.
auto scrollable_overflow_rect = paintable_box.absolute_padding_box_rect();
// - All line boxes directly contained by the scroll container.
LibWeb: Add virtuals to check if Paintable is PBox or PWithLines Instead of inferring the type of paintables by looking at the type of their origin in the layout tree, let's ask them directly.
2023-08-18 13:47:52 +02:00
if (is<Painting::PaintableWithLines>(box.paintable())) {
LibWeb: Use separate structure to represent fragments in paintable tree This is a part of refactoring towards making the paintable tree independent of the layout tree. Now, instead of transferring text fragments from the layout tree to the paintable tree during the layout commit phase, we allocate separate PaintableFragments that contain only the information necessary for painting. Doing this also allows us to get rid LineBoxes, as they are used only during layout.
2024-01-12 21:25:05 +01:00
for (auto const& fragment : static_cast<Painting::PaintableWithLines const&>(*box.paintable()).fragments()) {
scrollable_overflow_rect = scrollable_overflow_rect.united(fragment.absolute_rect());
LibWeb: Measure the overflow for all scroll containers Instead of just measuring the layout viewport, we now measure overflow in every box that is a scroll container. This has the side effect of no longer creating paintables for layout boxes that didn't participate in layout. (For example, empty/anonymous boxes that were ignored by flex itemization.) Such boxes are now marked as "(not painted)" in the layout tree dumps, as they have no paintable to dump geometry from.
2023-05-29 08:53:39 +02:00
}
LibWeb: Bring measuring of scrollable overflow closer to spec Importantly, we now only consider overflow from descendants with explicltly visible overflow, and only from descendants that have the measured box as their containing block. Also, we now measure scrollable overflow for all boxes, not just scroll containers. This will allow us to fix a long-standing paint problem in the next commit.
2023-07-12 18:55:23 +02:00
}
// - The border boxes of all boxes for which it is the containing block
// and whose border boxes are positioned not wholly in the negative scrollable overflow region,
// FIXME: accounting for transforms by projecting each box onto the plane of the element that establishes its 3D rendering context. [CSS3-TRANSFORMS]
if (!box.children_are_inline()) {
box.for_each_child_of_type<Box>([&box, &scrollable_overflow_rect](Box const& child) {
if (!child.paintable_box())
return IterationDecision::Continue;
auto child_border_box = child.paintable_box()->absolute_border_box_rect();
// NOTE: Here we check that the child is not wholly in the negative scrollable overflow region.
if (child_border_box.bottom() > 0 && child_border_box.right() > 0)
scrollable_overflow_rect = scrollable_overflow_rect.united(child_border_box);
// - The scrollable overflow areas of all of the above boxes
// (including zero-area boxes and accounting for transforms as described above),
// provided they themselves have overflow: visible (i.e. do not themselves trap the overflow)
// and that scrollable overflow is not already clipped (e.g. by the clip property or the contain property).
if (is<Viewport>(box) || child.computed_values().overflow_x() == CSS::Overflow::Visible || child.computed_values().overflow_y() == CSS::Overflow::Visible) {
auto child_scrollable_overflow = measure_scrollable_overflow(child);
if (is<Viewport>(box) || child.computed_values().overflow_x() == CSS::Overflow::Visible)
scrollable_overflow_rect.unite_horizontally(child_scrollable_overflow);
if (is<Viewport>(box) || child.computed_values().overflow_y() == CSS::Overflow::Visible)
scrollable_overflow_rect.unite_vertically(child_scrollable_overflow);
}
LibWeb: Measure the overflow for all scroll containers Instead of just measuring the layout viewport, we now measure overflow in every box that is a scroll container. This has the side effect of no longer creating paintables for layout boxes that didn't participate in layout. (For example, empty/anonymous boxes that were ignored by flex itemization.) Such boxes are now marked as "(not painted)" in the layout tree dumps, as they have no paintable to dump geometry from.
2023-05-29 08:53:39 +02:00
return IterationDecision::Continue;
});
}
LibWeb: Bring measuring of scrollable overflow closer to spec Importantly, we now only consider overflow from descendants with explicltly visible overflow, and only from descendants that have the measured box as their containing block. Also, we now measure scrollable overflow for all boxes, not just scroll containers. This will allow us to fix a long-standing paint problem in the next commit.
2023-07-12 18:55:23 +02:00
// FIXME: - The margin areas of grid item and flex item boxes for which the box establishes a containing block.
// FIXME: - Additional padding added to the end-side of the scrollable overflow rectangle as necessary
// to enable a scroll position that satisfies the requirements of place-content: end alignment.
paintable_box.set_overflow_data(Painting::PaintableBox::OverflowData {
.scrollable_overflow_rect = scrollable_overflow_rect,
.has_scrollable_overflow = !paintable_box.absolute_padding_box_rect().contains(scrollable_overflow_rect),
});
return scrollable_overflow_rect;
LibWeb: Measure the overflow for all scroll containers Instead of just measuring the layout viewport, we now measure overflow in every box that is a scroll container. This has the side effect of no longer creating paintables for layout boxes that didn't participate in layout. (For example, empty/anonymous boxes that were ignored by flex itemization.) Such boxes are now marked as "(not painted)" in the layout tree dumps, as they have no paintable to dump geometry from.
2023-05-29 08:53:39 +02:00
}
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
void LayoutState::resolve_relative_positions(Vector<Painting::PaintableWithLines&> const& paintables_with_lines)
{
// This function resolves relative position offsets of all the boxes & fragments in the paint tree.
// It runs *after* the paint tree has been constructed, so it modifies paintable node & fragment offsets directly.
// Regular boxes (not line box fragments):
for (auto& it : used_values_per_layout_node) {
auto& used_values = *it.value;
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
auto& node = const_cast<NodeWithStyle&>(used_values.node());
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
if (!node.is_box())
continue;
auto& paintable = static_cast<Painting::PaintableBox&>(*node.paintable());
CSSPixelPoint offset;
if (used_values.containing_line_box_fragment.has_value()) {
// Atomic inline case:
// We know that `node` is an atomic inline because `containing_line_box_fragments` refers to the
// line box fragment in the parent block container that contains it.
auto const& containing_line_box_fragment = used_values.containing_line_box_fragment.value();
auto const& containing_block = *node.containing_block();
LibWeb: Use separate structure to represent fragments in paintable tree This is a part of refactoring towards making the paintable tree independent of the layout tree. Now, instead of transferring text fragments from the layout tree to the paintable tree during the layout commit phase, we allocate separate PaintableFragments that contain only the information necessary for painting. Doing this also allows us to get rid LineBoxes, as they are used only during layout.
2024-01-12 21:25:05 +01:00
auto const& containing_block_used_values = get(containing_block);
auto const& fragment = containing_block_used_values.line_boxes[containing_line_box_fragment.line_box_index].fragments()[containing_line_box_fragment.fragment_index];
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
// The fragment has the final offset for the atomic inline, so we just need to copy it from there.
offset = fragment.offset();
} else {
// Not an atomic inline, much simpler case.
offset = used_values.offset;
}
// Apply relative position inset if appropriate.
LibWeb: Rename "position" enum to "positioning" The postitioning enum values are used by the position CSS property. Unfortunately, the prior naming clashes with the CSS Values-4 type named position, which will be implemented in a later commit.
2023-10-27 15:17:36 +02:00
if (node.computed_values().position() == CSS::Positioning::Relative && is<NodeWithStyleAndBoxModelMetrics>(node)) {
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
auto& inset = static_cast<NodeWithStyleAndBoxModelMetrics const&>(node).box_model().inset;
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
offset.translate_by(inset.left, inset.top);
}
paintable.set_offset(offset);
}
// Line box fragments:
for (auto const& paintable_with_lines : paintables_with_lines) {
LibWeb: Use separate structure to represent fragments in paintable tree This is a part of refactoring towards making the paintable tree independent of the layout tree. Now, instead of transferring text fragments from the layout tree to the paintable tree during the layout commit phase, we allocate separate PaintableFragments that contain only the information necessary for painting. Doing this also allows us to get rid LineBoxes, as they are used only during layout.
2024-01-12 21:25:05 +01:00
for (auto& fragment : paintable_with_lines.fragments()) {
auto const& fragment_node = fragment.layout_node();
if (!is<Layout::NodeWithStyleAndBoxModelMetrics>(*fragment_node.parent()))
continue;
// Collect effective relative position offset from inline-flow parent chain.
CSSPixelPoint offset;
for (auto* ancestor = fragment_node.parent(); ancestor; ancestor = ancestor->parent()) {
if (!is<Layout::NodeWithStyleAndBoxModelMetrics>(*ancestor))
break;
if (!ancestor->display().is_inline_outside() || !ancestor->display().is_flow_inside())
break;
if (ancestor->computed_values().position() == CSS::Positioning::Relative) {
auto const& ancestor_node = static_cast<Layout::NodeWithStyleAndBoxModelMetrics const&>(*ancestor);
auto const& inset = ancestor_node.box_model().inset;
offset.translate_by(inset.left, inset.top);
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
}
}
LibWeb: Use separate structure to represent fragments in paintable tree This is a part of refactoring towards making the paintable tree independent of the layout tree. Now, instead of transferring text fragments from the layout tree to the paintable tree during the layout commit phase, we allocate separate PaintableFragments that contain only the information necessary for painting. Doing this also allows us to get rid LineBoxes, as they are used only during layout.
2024-01-12 21:25:05 +01:00
const_cast<Painting::PaintableFragment&>(fragment).set_offset(fragment.offset().translated(offset));
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
}
}
}
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
static void build_paint_tree(Node& node, Painting::Paintable* parent_paintable = nullptr)
{
LibWeb: Create paintables for nodes whose parents don't have paintables A Paintable is not created for an SVG <defs> element (nor should it), but it can contain SVG <mask> elements that need a paintable. This change forces those paintables to be created (without a parent). The masks are then only painted by being referenced from another element.
2023-09-10 14:03:13 +01:00
Painting::Paintable* paintable = nullptr;
if (node.paintable()) {
paintable = const_cast<Painting::Paintable*>(node.paintable());
LibWeb: Layout SVG <mask> elements (but don't paint them) This allows SVG mask elements to have layout computed, but not connected to the main paint tree. They should only be reachable if (and painted) if referenced by the "mask" attribute of another element. This is controlled by the forms_unconnected_subtree() function on the paintable, which (if it returns true) prevents the paintable from being added as a child to what would be its parent.
2023-09-17 15:32:24 +01:00
if (parent_paintable && !paintable->forms_unconnected_subtree()) {
LibWeb: Create paintables for nodes whose parents don't have paintables A Paintable is not created for an SVG <defs> element (nor should it), but it can contain SVG <mask> elements that need a paintable. This change forces those paintables to be created (without a parent). The masks are then only painted by being referenced from another element.
2023-09-10 14:03:13 +01:00
VERIFY(!paintable->parent());
parent_paintable->append_child(*paintable);
}
paintable->set_dom_node(node.dom_node());
if (node.dom_node())
node.dom_node()->set_paintable(paintable);
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
}
for (auto* child = node.first_child(); child; child = child->next_sibling()) {
LibWeb: Create paintables for nodes whose parents don't have paintables A Paintable is not created for an SVG <defs> element (nor should it), but it can contain SVG <mask> elements that need a paintable. This change forces those paintables to be created (without a parent). The masks are then only painted by being referenced from another element.
2023-09-10 14:03:13 +01:00
build_paint_tree(*child, paintable);
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
}
}
LibWeb: Resolve border radius during layout and save it in paintables This change fixes a problem that we should not call `to_px()` to resolve any length or percentage values during paintables traversal because that is supposed to happen while performing layout. Also it improves performance because before we were resolving border radii during each painting phase but now it happens only once during layout.
2023-12-07 06:16:17 +01:00
static Painting::BorderRadiiData normalized_border_radii_data(Layout::Node const& node, CSSPixelRect const& rect, CSS::BorderRadiusData top_left_radius, CSS::BorderRadiusData top_right_radius, CSS::BorderRadiusData bottom_right_radius, CSS::BorderRadiusData bottom_left_radius)
{
Painting::BorderRadiusData bottom_left_radius_px {};
Painting::BorderRadiusData bottom_right_radius_px {};
Painting::BorderRadiusData top_left_radius_px {};
Painting::BorderRadiusData top_right_radius_px {};
bottom_left_radius_px.horizontal_radius = bottom_left_radius.horizontal_radius.to_px(node, rect.width());
bottom_right_radius_px.horizontal_radius = bottom_right_radius.horizontal_radius.to_px(node, rect.width());
top_left_radius_px.horizontal_radius = top_left_radius.horizontal_radius.to_px(node, rect.width());
top_right_radius_px.horizontal_radius = top_right_radius.horizontal_radius.to_px(node, rect.width());
bottom_left_radius_px.vertical_radius = bottom_left_radius.vertical_radius.to_px(node, rect.height());
bottom_right_radius_px.vertical_radius = bottom_right_radius.vertical_radius.to_px(node, rect.height());
top_left_radius_px.vertical_radius = top_left_radius.vertical_radius.to_px(node, rect.height());
top_right_radius_px.vertical_radius = top_right_radius.vertical_radius.to_px(node, rect.height());
// Scale overlapping curves according to https://www.w3.org/TR/css-backgrounds-3/#corner-overlap
// Let f = min(Li/Si), where i ∈ {top, right, bottom, left},
// Si is the sum of the two corresponding radii of the corners on side i,
// and Ltop = Lbottom = the width of the box, and Lleft = Lright = the height of the box.
auto l_top = rect.width();
auto l_bottom = l_top;
auto l_left = rect.height();
auto l_right = l_left;
auto s_top = (top_left_radius_px.horizontal_radius + top_right_radius_px.horizontal_radius);
auto s_right = (top_right_radius_px.vertical_radius + bottom_right_radius_px.vertical_radius);
auto s_bottom = (bottom_left_radius_px.horizontal_radius + bottom_right_radius_px.horizontal_radius);
auto s_left = (top_left_radius_px.vertical_radius + bottom_left_radius_px.vertical_radius);
CSSPixelFraction f = 1;
f = min(f, l_top / s_top);
f = min(f, l_right / s_right);
f = min(f, l_bottom / s_bottom);
f = min(f, l_left / s_left);
// If f < 1, then all corner radii are reduced by multiplying them by f.
if (f < 1) {
top_left_radius_px.horizontal_radius *= f;
top_left_radius_px.vertical_radius *= f;
top_right_radius_px.horizontal_radius *= f;
top_right_radius_px.vertical_radius *= f;
bottom_right_radius_px.horizontal_radius *= f;
bottom_right_radius_px.vertical_radius *= f;
bottom_left_radius_px.horizontal_radius *= f;
bottom_left_radius_px.vertical_radius *= f;
}
return Painting::BorderRadiiData { top_left_radius_px, top_right_radius_px, bottom_right_radius_px, bottom_left_radius_px };
}
void LayoutState::resolve_border_radii()
{
Vector<Painting::InlinePaintable&> inline_paintables;
for (auto& it : used_values_per_layout_node) {
auto& used_values = *it.value;
auto& node = const_cast<NodeWithStyle&>(used_values.node());
auto* paintable = node.paintable();
if (paintable && is<Painting::InlinePaintable>(*paintable)) {
auto& inline_paintable = static_cast<Painting::InlinePaintable&>(*paintable);
inline_paintables.append(inline_paintable);
}
if (paintable && is<Painting::PaintableBox>(*paintable)) {
auto& paintable_box = static_cast<Painting::PaintableBox&>(*paintable);
LibWeb: Take padding into account when resolving border radii Before this change, we were resolving border radii values based on content box + border widths only, ignoring padding.
2024-01-07 16:19:47 +01:00
CSSPixelRect const border_rect { 0, 0, used_values.border_box_width(), used_values.border_box_height() };
LibWeb: Resolve border radius during layout and save it in paintables This change fixes a problem that we should not call `to_px()` to resolve any length or percentage values during paintables traversal because that is supposed to happen while performing layout. Also it improves performance because before we were resolving border radii during each painting phase but now it happens only once during layout.
2023-12-07 06:16:17 +01:00
auto const& border_top_left_radius = node.computed_values().border_top_left_radius();
auto const& border_top_right_radius = node.computed_values().border_top_right_radius();
auto const& border_bottom_right_radius = node.computed_values().border_bottom_right_radius();
auto const& border_bottom_left_radius = node.computed_values().border_bottom_left_radius();
auto radii_data = normalized_border_radii_data(node, border_rect, border_top_left_radius, border_top_right_radius, border_bottom_right_radius, border_bottom_left_radius);
paintable_box.set_border_radii_data(radii_data);
}
}
for (auto& inline_paintable : inline_paintables) {
LibWeb: Use separate structure to represent fragments in paintable tree This is a part of refactoring towards making the paintable tree independent of the layout tree. Now, instead of transferring text fragments from the layout tree to the paintable tree during the layout commit phase, we allocate separate PaintableFragments that contain only the information necessary for painting. Doing this also allows us to get rid LineBoxes, as they are used only during layout.
2024-01-12 21:25:05 +01:00
Vector<Painting::PaintableFragment&> fragments;
LibWeb: Resolve border radius during layout and save it in paintables This change fixes a problem that we should not call `to_px()` to resolve any length or percentage values during paintables traversal because that is supposed to happen while performing layout. Also it improves performance because before we were resolving border radii during each painting phase but now it happens only once during layout.
2023-12-07 06:16:17 +01:00
verify_cast<Painting::PaintableWithLines>(*inline_paintable.containing_block()->paintable_box()).for_each_fragment([&](auto& fragment) {
if (inline_paintable.layout_node().is_inclusive_ancestor_of(fragment.layout_node()))
LibWeb: Use separate structure to represent fragments in paintable tree This is a part of refactoring towards making the paintable tree independent of the layout tree. Now, instead of transferring text fragments from the layout tree to the paintable tree during the layout commit phase, we allocate separate PaintableFragments that contain only the information necessary for painting. Doing this also allows us to get rid LineBoxes, as they are used only during layout.
2024-01-12 21:25:05 +01:00
fragments.append(const_cast<Painting::PaintableFragment&>(fragment));
LibWeb: Resolve border radius during layout and save it in paintables This change fixes a problem that we should not call `to_px()` to resolve any length or percentage values during paintables traversal because that is supposed to happen while performing layout. Also it improves performance because before we were resolving border radii during each painting phase but now it happens only once during layout.
2023-12-07 06:16:17 +01:00
return IterationDecision::Continue;
});
auto const& top_left_border_radius = inline_paintable.computed_values().border_top_left_radius();
auto const& top_right_border_radius = inline_paintable.computed_values().border_top_right_radius();
auto const& bottom_right_border_radius = inline_paintable.computed_values().border_bottom_right_radius();
auto const& bottom_left_border_radius = inline_paintable.computed_values().border_bottom_left_radius();
auto containing_block_position_in_absolute_coordinates = inline_paintable.containing_block()->paintable_box()->absolute_position();
for (size_t i = 0; i < fragments.size(); ++i) {
auto is_first_fragment = i == 0;
auto is_last_fragment = i == fragments.size() - 1;
auto& fragment = fragments[i];
CSSPixelRect absolute_fragment_rect { containing_block_position_in_absolute_coordinates.translated(fragment.offset()), fragment.size() };
if (is_first_fragment) {
auto extra_start_width = inline_paintable.box_model().padding.left;
absolute_fragment_rect.translate_by(-extra_start_width, 0);
absolute_fragment_rect.set_width(absolute_fragment_rect.width() + extra_start_width);
}
if (is_last_fragment) {
auto extra_end_width = inline_paintable.box_model().padding.right;
absolute_fragment_rect.set_width(absolute_fragment_rect.width() + extra_end_width);
}
auto border_radii_data = normalized_border_radii_data(inline_paintable.layout_node(), absolute_fragment_rect, top_left_border_radius, top_right_border_radius, bottom_right_border_radius, bottom_left_border_radius);
fragment.set_border_radii_data(border_radii_data);
}
}
}
LibWeb: Resolve box shadow data for paintable boxes during layout Step towards making the paintable tree independent of the layout tree.
2023-12-19 19:42:00 +01:00
void LayoutState::resolve_box_shadow_data()
{
for (auto& it : used_values_per_layout_node) {
auto& used_values = *it.value;
auto& node = const_cast<NodeWithStyle&>(used_values.node());
auto* paintable = node.paintable();
if (paintable && is<Painting::PaintableBox>(*paintable)) {
auto box_shadow_data = node.computed_values().box_shadow();
if (box_shadow_data.is_empty())
continue;
auto& paintable_box = static_cast<Painting::PaintableBox&>(*paintable);
Vector<Painting::ShadowData> resolved_box_shadow_data;
resolved_box_shadow_data.ensure_capacity(box_shadow_data.size());
for (auto const& layer : box_shadow_data) {
resolved_box_shadow_data.empend(
layer.color,
layer.offset_x.to_px(node),
layer.offset_y.to_px(node),
layer.blur_radius.to_px(node),
layer.spread_distance.to_px(node),
layer.placement == CSS::ShadowPlacement::Outer ? Painting::ShadowPlacement::Outer : Painting::ShadowPlacement::Inner);
}
paintable_box.set_box_shadow_data(move(resolved_box_shadow_data));
}
}
}
LibWeb: Resolve text shadows in `LayoutState::commit()` Rather than resolving the text-shadow each time painting commands are recorded, we can resolve it once during the layout commit and save the resolved values in paintable fragments. This is also step towards getting rid of layout node pointer in paintable fragment.
2024-01-13 10:38:07 +01:00
void LayoutState::resolve_text_shadows(Vector<Painting::PaintableWithLines&> const& paintables_with_lines)
{
for (auto const& paintable_with_lines : paintables_with_lines) {
for (auto const& fragment : paintable_with_lines.fragments()) {
auto const& text_shadow = fragment.m_layout_node->computed_values().text_shadow();
if (!text_shadow.is_empty()) {
Vector<Painting::ShadowData> resolved_shadow_data;
resolved_shadow_data.ensure_capacity(text_shadow.size());
for (auto const& layer : text_shadow) {
resolved_shadow_data.empend(
layer.color,
layer.offset_x.to_px(paintable_with_lines.layout_node()),
layer.offset_y.to_px(paintable_with_lines.layout_node()),
layer.blur_radius.to_px(paintable_with_lines.layout_node()),
layer.spread_distance.to_px(paintable_with_lines.layout_node()),
Painting::ShadowPlacement::Outer);
}
const_cast<Painting::PaintableFragment&>(fragment).set_shadows(move(resolved_shadow_data));
}
}
}
}
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
void LayoutState::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 FormattingState to LayoutState This seems a bit more descriptive (and also a bit shorter).
2022-07-16 23:30:32 +02:00
// Only the top-level LayoutState should ever be committed.
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
VERIFY(!m_parent);
LibWeb: Prune old paintable pointers from layout tree after relayout When text paintables shift around in the tree due to line wrapping, we may end up in a situation where some text node does not generate a paintable (due to being all whitespace, for example), even though in the previous layout pass, it *did* generate a paintable. To prevent holding on to old paintables in such cases, we now do a pass in LayoutState::commit() where we explicitly detach all old paintables from the layout tree.
2023-08-29 16:27:16 +02:00
// NOTE: In case this is a relayout of an existing tree, we start by detaching the old paint tree
// from the layout tree. This is done to ensure that we don't end up with any old-tree pointers
// when text paintables shift around in the tree.
root.for_each_in_inclusive_subtree_of_type<Layout::TextNode>([&](Layout::TextNode& text_node) {
text_node.set_paintable(nullptr);
return IterationDecision::Continue;
});
LibWeb: Generate a TextPaintable for every Layout::TextNode This is prep work for moving event handling over to the painting tree.
2022-03-10 16:46:44 +01:00
HashTable<Layout::TextNode*> text_nodes;
LibWeb: Add LineBox::absolute_rect() Let's just calculate this once, at the end of a layout, and then never have to worry about it again during painting.
2023-07-12 15:41:30 +02:00
Vector<Painting::PaintableWithLines&> paintables_with_lines;
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
for (auto& it : used_values_per_layout_node) {
auto& used_values = *it.value;
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
auto& node = const_cast<NodeWithStyle&>(used_values.node());
if (is<NodeWithStyleAndBoxModelMetrics>(node)) {
// Transfer box model metrics.
auto& box_model = static_cast<NodeWithStyleAndBoxModelMetrics&>(node).box_model();
box_model.inset = { used_values.inset_top, used_values.inset_right, used_values.inset_bottom, used_values.inset_left };
box_model.padding = { used_values.padding_top, used_values.padding_right, used_values.padding_bottom, used_values.padding_left };
box_model.border = { used_values.border_top, used_values.border_right, used_values.border_bottom, used_values.border_left };
box_model.margin = { used_values.margin_top, used_values.margin_right, used_values.margin_bottom, used_values.margin_left };
}
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
auto paintable = node.create_paintable();
node.set_paintable(paintable);
LibWeb: Split Paintable into Paintable and PaintableBox To prepare for paintable inline content, we take the basic painting functionality and hoist it into a base class.
2022-03-10 15:50:57 +01:00
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
// For boxes, transfer all the state needed for painting.
LibWeb: Add virtuals to check if Paintable is PBox or PWithLines Instead of inferring the type of paintables by looking at the type of their origin in the layout tree, let's ask them directly.
2023-08-18 13:47:52 +02:00
if (paintable && is<Painting::PaintableBox>(*paintable)) {
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
auto& paintable_box = static_cast<Painting::PaintableBox&>(*paintable);
LibWeb/Layout: Rename BlockContainer::paint{_box => able_with_lines}() It returns a PaintableBox (a PaintableWithLines, to be specific), not a 'PaintBox'. paintable_box() without the cast is already available through BlockContainer's Box base class, we don't need to shadow it.
2023-04-20 16:01:38 +01:00
paintable_box.set_offset(used_values.offset);
paintable_box.set_content_size(used_values.content_width(), used_values.content_height());
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
if (used_values.override_borders_data().has_value()) {
paintable_box.set_override_borders_data(used_values.override_borders_data().value());
}
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
if (used_values.table_cell_coordinates().has_value()) {
paintable_box.set_table_cell_coordinates(used_values.table_cell_coordinates().value());
}
LibWeb: Make Painting::Box virtual and add Painting::BoxWithLines BlockContainer paint boxes are the only ones that have line boxes associated, so let's not waste memory on line boxes in all the other types of boxes. This also adds Layout::Box::paint_box() and the more tightly typed Layout::BlockContainer::paint_box() to get at the paint box from the corresponding layout box.
2022-03-10 11:12:06 +01:00
LibWeb: Add virtuals to check if Paintable is PBox or PWithLines Instead of inferring the type of paintables by looking at the type of their origin in the layout tree, let's ask them directly.
2023-08-18 13:47:52 +02:00
if (is<Painting::PaintableWithLines>(paintable_box)) {
LibWeb: Add LineBox::absolute_rect() Let's just calculate this once, at the end of a layout, and then never have to worry about it again during painting.
2023-07-12 15:41:30 +02:00
auto& paintable_with_lines = static_cast<Painting::PaintableWithLines&>(paintable_box);
LibWeb: Use separate structure to represent fragments in paintable tree This is a part of refactoring towards making the paintable tree independent of the layout tree. Now, instead of transferring text fragments from the layout tree to the paintable tree during the layout commit phase, we allocate separate PaintableFragments that contain only the information necessary for painting. Doing this also allows us to get rid LineBoxes, as they are used only during layout.
2024-01-12 21:25:05 +01:00
for (auto& line_box : used_values.line_boxes) {
for (auto& fragment : line_box.fragments())
paintable_with_lines.add_fragment(fragment);
}
LibWeb: Add LineBox::absolute_rect() Let's just calculate this once, at the end of a layout, and then never have to worry about it again during painting.
2023-07-12 15:41:30 +02:00
paintables_with_lines.append(paintable_with_lines);
}
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: 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
if (used_values.computed_svg_transforms().has_value() && is<Painting::SVGGraphicsPaintable>(paintable_box)) {
auto& svg_graphics_paintable = static_cast<Painting::SVGGraphicsPaintable&>(paintable_box);
svg_graphics_paintable.set_computed_transforms(*used_values.computed_svg_transforms());
}
LibWeb: Support transforms, stroking, gradients, etc for SVG <text> This makes use of the new Gfx::Path::text() to handle SVG text elements, with this text is just a regular path, and can be manipulated like any other graphics element. This removes the SVGTextPaintable and makes both <text> and geometry elements use a new (shared) SVGPathPaintable. This is identical to the old SVGGeometryPaintable. This simplifies painting as once something is resolved to a Gfx::Path, the painting logic is the same.
2023-11-04 21:31:35 +00:00
if (used_values.computed_svg_path().has_value() && is<Painting::SVGPathPaintable>(paintable_box)) {
auto& svg_geometry_paintable = static_cast<Painting::SVGPathPaintable&>(paintable_box);
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
svg_geometry_paintable.set_computed_path(move(*used_values.computed_svg_path()));
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: Add LineBox::absolute_rect() Let's just calculate this once, at the end of a layout, and then never have to worry about it again during painting.
2023-07-12 15:41:30 +02:00
}
}
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
resolve_relative_positions(paintables_with_lines);
// Make a pass over all the line boxes to:
// - Measure absolute rect of each line box.
// - Collect all text nodes, so we can create paintables for them later.
LibWeb: Add LineBox::absolute_rect() Let's just calculate this once, at the end of a layout, and then never have to worry about it again during painting.
2023-07-12 15:41:30 +02:00
for (auto& paintable_with_lines : paintables_with_lines) {
LibWeb: Use separate structure to represent fragments in paintable tree This is a part of refactoring towards making the paintable tree independent of the layout tree. Now, instead of transferring text fragments from the layout tree to the paintable tree during the layout commit phase, we allocate separate PaintableFragments that contain only the information necessary for painting. Doing this also allows us to get rid LineBoxes, as they are used only during layout.
2024-01-12 21:25:05 +01:00
for (auto& fragment : paintable_with_lines.fragments()) {
if (fragment.layout_node().is_text_node())
text_nodes.set(static_cast<Layout::TextNode*>(const_cast<Layout::Node*>(&fragment.layout_node())));
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: Generate a TextPaintable for every Layout::TextNode This is prep work for moving event handling over to the painting tree.
2022-03-10 16:46:44 +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
for (auto* text_node : text_nodes)
text_node->set_paintable(text_node->create_paintable());
build_paint_tree(root);
LibWeb: Measure the overflow for all scroll containers Instead of just measuring the layout viewport, we now measure overflow in every box that is a scroll container. This has the side effect of no longer creating paintables for layout boxes that didn't participate in layout. (For example, empty/anonymous boxes that were ignored by flex itemization.) Such boxes are now marked as "(not painted)" in the layout tree dumps, as they have no paintable to dump geometry from.
2023-05-29 08:53:39 +02:00
// Measure overflow in scroll containers.
for (auto& it : used_values_per_layout_node) {
auto& used_values = *it.value;
if (!used_values.node().is_box())
continue;
auto const& box = static_cast<Layout::Box const&>(used_values.node());
LibWeb: Bring measuring of scrollable overflow closer to spec Importantly, we now only consider overflow from descendants with explicltly visible overflow, and only from descendants that have the measured box as their containing block. Also, we now measure scrollable overflow for all boxes, not just scroll containers. This will allow us to fix a long-standing paint problem in the next commit.
2023-07-12 18:55:23 +02:00
measure_scrollable_overflow(box);
LibWeb: Measure the overflow for all scroll containers Instead of just measuring the layout viewport, we now measure overflow in every box that is a scroll container. This has the side effect of no longer creating paintables for layout boxes that didn't participate in layout. (For example, empty/anonymous boxes that were ignored by flex itemization.) Such boxes are now marked as "(not painted)" in the layout tree dumps, as they have no paintable to dump geometry from.
2023-05-29 08:53:39 +02:00
}
LibWeb: Resolve border radius during layout and save it in paintables This change fixes a problem that we should not call `to_px()` to resolve any length or percentage values during paintables traversal because that is supposed to happen while performing layout. Also it improves performance because before we were resolving border radii during each painting phase but now it happens only once during layout.
2023-12-07 06:16:17 +01:00
resolve_border_radii();
LibWeb: Resolve box shadow data for paintable boxes during layout Step towards making the paintable tree independent of the layout tree.
2023-12-19 19:42:00 +01:00
resolve_box_shadow_data();
LibWeb: Resolve text shadows in `LayoutState::commit()` Rather than resolving the text-shadow each time painting commands are recorded, we can resolve it once during the layout commit and save the resolved values in paintable fragments. This is also step towards getting rid of layout node pointer in paintable fragment.
2024-01-13 10:38:07 +01:00
resolve_text_shadows(paintables_with_lines);
LibWeb: Paint fragments contained by inline node as part of this node Fragments contained by the inline node should be painted in the foreground phase for this node, instead of being painted as a part of the containing PaintableWithLines. This change implements that by marking all fragments contained by inline nodes so they can be skipped while painting the content of PaintableWithLines. This is an ugly way, and instead, we should make InlinePaintables own all fragments contained by them.
2024-01-03 19:00:04 +01:00
for (auto& it : used_values_per_layout_node) {
auto& used_values = *it.value;
auto& node = const_cast<NodeWithStyle&>(used_values.node());
auto* paintable = node.paintable();
if (paintable && is<Painting::InlinePaintable>(*paintable)) {
auto& inline_paintable = static_cast<Painting::InlinePaintable&>(*paintable);
// FIXME: Marking fragments contained by inline node is a hack required to skip them while painting
// PaintableWithLines content.
inline_paintable.mark_contained_fragments();
}
}
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: 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
void LayoutState::UsedValues::set_node(NodeWithStyle& node, UsedValues const* containing_block_used_values)
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
{
m_node = &node;
LibWeb: Apply min/max constraints to sizes that are initially definite Also add a comment explaining how we determine initial definite sizes.
2022-10-13 14:49:08 +02:00
// NOTE: In the code below, we decide if `node` has definite width and/or height.
// This attempts to cover all the *general* cases where CSS considers sizes to be definite.
// If `node` has definite values for min/max-width or min/max-height and a definite
// preferred size in the same axis, we clamp the preferred size here as well.
//
// There are additional cases where CSS considers values to be definite. We model all of
// those by having our engine consider sizes to be definite *once they are assigned to
// the UsedValues by calling set_content_width() or set_content_height().
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
auto const& computed_values = node.computed_values();
LibWeb: Account for box-sizing:border-box in layout-less definite sizes When we determine that a size is definite because it can be resolved now without performing layout, we also need to account for the box-sizing property. This lets us remove a hack from flex layout where box-sizing:border-box was manually undone at one point in the layout algorithm.
2023-05-02 06:51:32 +02:00
auto adjust_for_box_sizing = [&](CSSPixels unadjusted_pixels, CSS::Size const& computed_size, bool width) -> CSSPixels {
// box-sizing: content-box and/or automatic size don't require any adjustment.
if (computed_values.box_sizing() == CSS::BoxSizing::ContentBox || computed_size.is_auto())
return unadjusted_pixels;
// box-sizing: border-box requires us to subtract the relevant border and padding from the size.
CSSPixels border_and_padding;
if (width) {
LibWeb: Convert BorderData::width to CSSPixels The `clip_shrink` optimization in `paint_background()` now also correctly uses DevicePixels, instead of reducing a DevicePixel rect by a CSSPixels amount.
2023-07-30 15:54:57 +01:00
border_and_padding = computed_values.border_left().width
LibWeb: Get rid of weird Length::resolved() usage in LayoutState The second call to resolved() turns non-finite lengths into "auto". This is a very strange ad-hoc behavior that we need to get rid of.
2023-05-06 17:15:53 +02:00
+ computed_values.padding().left().to_px(*m_node, containing_block_used_values->content_width())
LibWeb: Convert BorderData::width to CSSPixels The `clip_shrink` optimization in `paint_background()` now also correctly uses DevicePixels, instead of reducing a DevicePixel rect by a CSSPixels amount.
2023-07-30 15:54:57 +01:00
+ computed_values.border_right().width
LibWeb: Get rid of weird Length::resolved() usage in LayoutState The second call to resolved() turns non-finite lengths into "auto". This is a very strange ad-hoc behavior that we need to get rid of.
2023-05-06 17:15:53 +02:00
+ computed_values.padding().right().to_px(*m_node, containing_block_used_values->content_width());
LibWeb: Account for box-sizing:border-box in layout-less definite sizes When we determine that a size is definite because it can be resolved now without performing layout, we also need to account for the box-sizing property. This lets us remove a hack from flex layout where box-sizing:border-box was manually undone at one point in the layout algorithm.
2023-05-02 06:51:32 +02:00
} else {
LibWeb: Convert BorderData::width to CSSPixels The `clip_shrink` optimization in `paint_background()` now also correctly uses DevicePixels, instead of reducing a DevicePixel rect by a CSSPixels amount.
2023-07-30 15:54:57 +01:00
border_and_padding = computed_values.border_top().width
LibWeb: Get rid of weird Length::resolved() usage in LayoutState The second call to resolved() turns non-finite lengths into "auto". This is a very strange ad-hoc behavior that we need to get rid of.
2023-05-06 17:15:53 +02:00
+ computed_values.padding().top().to_px(*m_node, containing_block_used_values->content_width())
LibWeb: Convert BorderData::width to CSSPixels The `clip_shrink` optimization in `paint_background()` now also correctly uses DevicePixels, instead of reducing a DevicePixel rect by a CSSPixels amount.
2023-07-30 15:54:57 +01:00
+ computed_values.border_bottom().width
LibWeb: Get rid of weird Length::resolved() usage in LayoutState The second call to resolved() turns non-finite lengths into "auto". This is a very strange ad-hoc behavior that we need to get rid of.
2023-05-06 17:15:53 +02:00
+ computed_values.padding().bottom().to_px(*m_node, containing_block_used_values->content_width());
LibWeb: Account for box-sizing:border-box in layout-less definite sizes When we determine that a size is definite because it can be resolved now without performing layout, we also need to account for the box-sizing property. This lets us remove a hack from flex layout where box-sizing:border-box was manually undone at one point in the layout algorithm.
2023-05-02 06:51:32 +02:00
}
return unadjusted_pixels - border_and_padding;
};
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
auto is_definite_size = [&](CSS::Size const& size, CSSPixels& resolved_definite_size, bool width) {
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
// A size that can be determined without performing layout; that is,
// a <length>,
// a measure of text (without consideration of line-wrapping),
// a size of the initial containing block,
// or a <percentage> or other formula (such as the “stretch-fit” sizing of non-replaced blocks [CSS2]) that is resolved solely against definite sizes.
auto containing_block_has_definite_size = containing_block_used_values ? (width ? containing_block_used_values->has_definite_width() : containing_block_used_values->has_definite_height()) : false;
if (size.is_auto()) {
// NOTE: The width of a non-flex-item block is considered definite if it's auto and the containing block has definite width.
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
if (width
LibWeb: Floating boxes with width:auto don't have definite width Since layout is required in order to determine the width of such boxes, they should not be marked as having definite width initially.
2022-10-07 13:07:40 +02:00
&& !node.is_floating()
LibWeb: Do not treat size of abspos items as definite This fixes the issue when size of abspos items is considered to be resolvable without performing layout which is not correct in the scenarious when top/right/bottom/left properties are not auto.
2023-06-22 18:02:04 +03:00
&& !node.is_absolutely_positioned()
LibWeb: Use Layout::Node::display() everywhere
2022-10-06 16:02:53 +02:00
&& node.display().is_block_outside()
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
&& node.parent()
&& !node.parent()->is_floating()
LibWeb: Use Layout::Node::display() everywhere
2022-10-06 16:02:53 +02:00
&& (node.parent()->display().is_flow_root_inside()
|| node.parent()->display().is_flow_inside())) {
LibWeb: Resolve definite sizes when instantiating UsedValues When we decide that a box has definite width or height based on its containing block's corresponding size, we'll want to resolve the current box's size as well. Otherwise anyone querying the size on this box will get the bogus message of "yes, this definite, and its value is zero."
2022-07-19 13:46:27 +02:00
if (containing_block_has_definite_size) {
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels available_width = containing_block_used_values->content_width();
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
resolved_definite_size = available_width
- margin_left
- margin_right
- padding_left
- padding_right
- border_left
- border_right;
LibWeb: Resolve definite sizes when instantiating UsedValues When we decide that a box has definite width or height based on its containing block's corresponding size, we'll want to resolve the current box's size as well. Otherwise anyone querying the size on this box will get the bogus message of "yes, this definite, and its value is zero."
2022-07-19 13:46:27 +02:00
return true;
}
return false;
}
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
return false;
}
LibWeb: Remove CalculatedStyleValue from Length
2023-03-30 15:46:05 +01:00
if (size.is_calculated()) {
if (size.calculated().contains_percentage()) {
LibWeb: Mark percentage heights as initially definite when appropriate Percentage heights are now considered definite when their containing block has a definite height. This makes profile pictures have geometry on Twitter. (We still don't load the images themselves though.)
2022-10-13 11:16:54 +02:00
if (!containing_block_has_definite_size)
return false;
LibWeb: Add `Length::resolved()` overload for CSSPixels Since we always pass the px value as an argument to resolved(), we can pass it directly as CSSPixels instead of wrapping it in Length. This approach allows us to avoid converting to a double, resulting in fewer precision issues.
2023-08-29 18:57:09 +02:00
auto containing_block_size_as_length = width ? containing_block_used_values->content_width() : containing_block_used_values->content_height();
LibWeb: Account for box-sizing:border-box in layout-less definite sizes When we determine that a size is definite because it can be resolved now without performing layout, we also need to account for the box-sizing property. This lets us remove a hack from flex layout where box-sizing:border-box was manually undone at one point in the layout algorithm.
2023-05-02 06:51:32 +02:00
resolved_definite_size = adjust_for_box_sizing(size.calculated().resolve_length_percentage(node, containing_block_size_as_length).value_or(CSS::Length::make_auto()).to_px(node), size, width);
LibWeb: Mark percentage heights as initially definite when appropriate Percentage heights are now considered definite when their containing block has a definite height. This makes profile pictures have geometry on Twitter. (We still don't load the images themselves though.)
2022-10-13 11:16:54 +02:00
return true;
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
}
LibWeb: Account for box-sizing:border-box in layout-less definite sizes When we determine that a size is definite because it can be resolved now without performing layout, we also need to account for the box-sizing property. This lets us remove a hack from flex layout where box-sizing:border-box was manually undone at one point in the layout algorithm.
2023-05-02 06:51:32 +02:00
resolved_definite_size = adjust_for_box_sizing(size.calculated().resolve_length(node)->to_px(node), size, width);
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
return true;
LibWeb: Resolve definite sizes when instantiating UsedValues When we decide that a box has definite width or height based on its containing block's corresponding size, we'll want to resolve the current box's size as well. Otherwise anyone querying the size on this box will get the bogus message of "yes, this definite, and its value is zero."
2022-07-19 13:46:27 +02:00
}
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
if (size.is_length()) {
LibWeb: Remove CalculatedStyleValue from Length
2023-03-30 15:46:05 +01:00
VERIFY(!size.is_auto()); // This should have been covered by the Size::is_auto() branch above.
LibWeb: Account for box-sizing:border-box in layout-less definite sizes When we determine that a size is definite because it can be resolved now without performing layout, we also need to account for the box-sizing property. This lets us remove a hack from flex layout where box-sizing:border-box was manually undone at one point in the layout algorithm.
2023-05-02 06:51:32 +02:00
resolved_definite_size = adjust_for_box_sizing(size.length().to_px(node), size, width);
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
return true;
}
LibWeb: Resolve definite sizes when instantiating UsedValues When we decide that a box has definite width or height based on its containing block's corresponding size, we'll want to resolve the current box's size as well. Otherwise anyone querying the size on this box will get the bogus message of "yes, this definite, and its value is zero."
2022-07-19 13:46:27 +02:00
if (size.is_percentage()) {
if (containing_block_has_definite_size) {
auto containing_block_size = width ? containing_block_used_values->content_width() : containing_block_used_values->content_height();
LibWeb: Remove implicit conversion from float and double to CSSPixels In general it is not safe to convert any arbitrary floating-point value to CSSPixels. CSSPixels has a resolution of 0.015625, which for small values (e.g. scale factors between 0 and 1), can produce bad results if converted to CSSPixels then scaled back up. In the worst case values can underflow to zero and produce incorrect results.
2023-08-26 15:03:04 +01:00
resolved_definite_size = adjust_for_box_sizing(containing_block_size.scaled(size.percentage().as_fraction()), size, width);
LibWeb: Resolve definite sizes when instantiating UsedValues When we decide that a box has definite width or height based on its containing block's corresponding size, we'll want to resolve the current box's size as well. Otherwise anyone querying the size on this box will get the bogus message of "yes, this definite, and its value is zero."
2022-07-19 13:46:27 +02:00
return true;
}
return false;
}
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
// FIXME: Determine if calc() value is definite.
return false;
};
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels min_width = 0;
LibWeb: Apply min/max constraints to sizes that are initially definite Also add a comment explaining how we determine initial definite sizes.
2022-10-13 14:49:08 +02:00
bool has_definite_min_width = is_definite_size(computed_values.min_width(), min_width, true);
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels max_width = 0;
LibWeb: Apply min/max constraints to sizes that are initially definite Also add a comment explaining how we determine initial definite sizes.
2022-10-13 14:49:08 +02:00
bool has_definite_max_width = is_definite_size(computed_values.max_width(), max_width, true);
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels min_height = 0;
LibWeb: Apply min/max constraints to sizes that are initially definite Also add a comment explaining how we determine initial definite sizes.
2022-10-13 14:49:08 +02:00
bool has_definite_min_height = is_definite_size(computed_values.min_height(), min_height, false);
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels max_height = 0;
LibWeb: Apply min/max constraints to sizes that are initially definite Also add a comment explaining how we determine initial definite sizes.
2022-10-13 14:49:08 +02:00
bool has_definite_max_height = is_definite_size(computed_values.max_height(), max_height, false);
LibWeb: Resolve definite sizes when instantiating UsedValues When we decide that a box has definite width or height based on its containing block's corresponding size, we'll want to resolve the current box's size as well. Otherwise anyone querying the size on this box will get the bogus message of "yes, this definite, and its value is zero."
2022-07-19 13:46:27 +02:00
m_has_definite_width = is_definite_size(computed_values.width(), m_content_width, true);
m_has_definite_height = is_definite_size(computed_values.height(), m_content_height, false);
LibWeb: Apply min/max constraints to sizes that are initially definite Also add a comment explaining how we determine initial definite sizes.
2022-10-13 14:49:08 +02:00
if (m_has_definite_width) {
if (has_definite_min_width)
m_content_width = max(min_width, m_content_width);
if (has_definite_max_width)
m_content_width = min(max_width, m_content_width);
}
if (m_has_definite_height) {
if (has_definite_min_height)
m_content_height = max(min_height, m_content_height);
if (has_definite_max_height)
m_content_height = min(max_height, m_content_height);
}
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
void LayoutState::UsedValues::set_content_width(CSSPixels width)
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: Verify that value is not saturated in set_content_width/height Checking if CSSPixels contains a finite value is no longer makes sense after converting to fixed-point arithmetics. Instead there should assertion that used value is not saturated.
2023-07-26 14:50:12 +02:00
VERIFY(!width.might_be_saturated());
LibWeb: Add FIXME whining to debug log if layout produces negative sizes Negative width/height sizes are not allowed in CSS, so if our layout algorithm resolves something to a negative size, we have boogs. Instead of crashing or rendering something very wrong, we now clamp the values to 0 and whine on the debug log so that someone can go and figure out how we got the negative values in the first place. :^)
2023-03-25 17:33:22 +01:00
if (width < 0) {
LibWeb: Fix mistype in `LayoutState`
2023-03-26 22:25:53 +11:00
// Negative widths are not allowed in CSS. We have a bug somewhere! Clamp to 0 to avoid doing too much damage.
LibWeb: Put debug spam about negative content sizes behind a flag We already clamp these values to zero, so it's actually pretty harmless when this happens. If someone wants to investigate these issues deeper and see if they can be fixed earlier in the layout pipeline, they can enable the spam locally.
2023-05-31 11:47:26 +02:00
dbgln_if(LIBWEB_CSS_DEBUG, "FIXME: Layout calculated a negative width for {}: {}", m_node->debug_description(), width);
LibWeb: Add FIXME whining to debug log if layout produces negative sizes Negative width/height sizes are not allowed in CSS, so if our layout algorithm resolves something to a negative size, we have boogs. Instead of crashing or rendering something very wrong, we now clamp the values to 0 and whine on the debug log so that someone can go and figure out how we got the negative values in the first place. :^)
2023-03-25 17:33:22 +01:00
width = 0;
}
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
m_content_width = width;
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
m_has_definite_width = true;
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: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
void LayoutState::UsedValues::set_content_height(CSSPixels height)
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: Verify that value is not saturated in set_content_width/height Checking if CSSPixels contains a finite value is no longer makes sense after converting to fixed-point arithmetics. Instead there should assertion that used value is not saturated.
2023-07-26 14:50:12 +02:00
VERIFY(!height.might_be_saturated());
LibWeb: Add FIXME whining to debug log if layout produces negative sizes Negative width/height sizes are not allowed in CSS, so if our layout algorithm resolves something to a negative size, we have boogs. Instead of crashing or rendering something very wrong, we now clamp the values to 0 and whine on the debug log so that someone can go and figure out how we got the negative values in the first place. :^)
2023-03-25 17:33:22 +01:00
if (height < 0) {
// Negative heights are not allowed in CSS. We have a bug somewhere! Clamp to 0 to avoid doing too much damage.
LibWeb: Put debug spam about negative content sizes behind a flag We already clamp these values to zero, so it's actually pretty harmless when this happens. If someone wants to investigate these issues deeper and see if they can be fixed earlier in the layout pipeline, they can enable the spam locally.
2023-05-31 11:47:26 +02:00
dbgln_if(LIBWEB_CSS_DEBUG, "FIXME: Layout calculated a negative height for {}: {}", m_node->debug_description(), height);
LibWeb: Add FIXME whining to debug log if layout produces negative sizes Negative width/height sizes are not allowed in CSS, so if our layout algorithm resolves something to a negative size, we have boogs. Instead of crashing or rendering something very wrong, we now clamp the values to 0 and whine on the debug log so that someone can go and figure out how we got the negative values in the first place. :^)
2023-03-25 17:33:22 +01:00
height = 0;
}
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
m_content_height = height;
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
m_has_definite_height = true;
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: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
void LayoutState::UsedValues::set_temporary_content_width(CSSPixels width)
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
{
m_content_width = width;
}
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
void LayoutState::UsedValues::set_temporary_content_height(CSSPixels 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
{
m_content_height = height;
}
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 LayoutState::UsedValues::available_width_inside() const
{
if (width_constraint == SizeConstraint::MinContent)
return AvailableSize::make_min_content();
if (width_constraint == SizeConstraint::MaxContent)
return AvailableSize::make_max_content();
if (has_definite_width())
return AvailableSize::make_definite(m_content_width);
return AvailableSize::make_indefinite();
}
AvailableSize LayoutState::UsedValues::available_height_inside() const
{
if (height_constraint == SizeConstraint::MinContent)
return AvailableSize::make_min_content();
if (height_constraint == SizeConstraint::MaxContent)
return AvailableSize::make_max_content();
if (has_definite_height())
return AvailableSize::make_definite(m_content_height);
return AvailableSize::make_indefinite();
}
AvailableSpace LayoutState::UsedValues::available_inner_space_or_constraints_from(AvailableSpace const& outer_space) const
{
auto inner_width = available_width_inside();
auto inner_height = available_height_inside();
if (inner_width.is_indefinite() && outer_space.width.is_intrinsic_sizing_constraint())
inner_width = outer_space.width;
if (inner_height.is_indefinite() && outer_space.height.is_intrinsic_sizing_constraint())
inner_height = outer_space.height;
return AvailableSpace(inner_width, inner_height);
}
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
void LayoutState::UsedValues::set_content_offset(CSSPixelPoint new_offset)
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
{
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
set_content_x(new_offset.x());
set_content_y(new_offset.y());
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
}
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
void LayoutState::UsedValues::set_content_x(CSSPixels x)
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
{
offset.set_x(x);
}
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
void LayoutState::UsedValues::set_content_y(CSSPixels y)
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
{
offset.set_y(y);
LibWeb: Don't re-resolve "auto" flex item sizes after definitizing them This is rather subtle and points to our architecture around definite sizes not being exactly right, but... At some points during flexbox layout, the spec tells us that the sizes of certain flex items are considered definite from this point on. We implement this by marking each item's associated UsedValues as "has-definite-width/height". However, this breaks code that tries to resolve computed "auto" sizes by taking the corresponding size from the containing block. The end result was that the 1st sizing pass in flexbox would find the right size for an "auto" sized item, but the 2nd pass would override the correct size with the containing block's content size in that axis instead. To work around the issue, FFC now remembers when it "definitizes" an item, and future attempts to resolve an "auto" computed size for that value will bypass the computed-auto-is-resolved-against-containing-block step of the algorithm. It's not perfect, and we'll need to think more about how to really represent these intermediate states relating to box sizes being definite..
2022-09-14 11:43:57 +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 LayoutState::UsedValues::set_indefinite_content_width()
{
m_has_definite_width = false;
}
void LayoutState::UsedValues::set_indefinite_content_height()
{
m_has_definite_height = false;
}
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
}
Reference in a new issue Copy permalink