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

408 lines
17 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: 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
#include <LibWeb/Layout/TextNode.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: 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
LayoutState::UsedValues& LayoutState::get_mutable(NodeWithStyleAndBoxModelMetrics const& box)
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: 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
if (auto* used_values = used_values_per_layout_node.get(&box).value_or(nullptr))
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: 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
if (auto* ancestor_used_values = ancestor->used_values_per_layout_node.get(&box).value_or(nullptr)) {
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: 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
used_values_per_layout_node.set(&box, 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: Rename Layout::InitialContainingBlock to Layout::Viewport The name "initial containing block" was wrong for this, as it doesn't correspond to the HTML element, and that's specifically what it's supposed to do! :^)
2023-02-25 11:04:29 +01:00
auto const* containing_block_used_values = box.is_viewport() ? nullptr : &get(*box.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();
new_used_values->set_node(const_cast<NodeWithStyleAndBoxModelMetrics&>(box), containing_block_used_values);
used_values_per_layout_node.set(&box, move(new_used_values));
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: 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
LayoutState::UsedValues const& LayoutState::get(NodeWithStyleAndBoxModelMetrics const& box) 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: 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
if (auto const* used_values = used_values_per_layout_node.get(&box).value_or(nullptr))
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) {
if (auto const* ancestor_used_values = ancestor->used_values_per_layout_node.get(&box).value_or(nullptr))
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: Rename Layout::InitialContainingBlock to Layout::Viewport The name "initial containing block" was wrong for this, as it doesn't correspond to the HTML element, and that's specifically what it's supposed to do! :^)
2023-02-25 11:04:29 +01:00
auto const* containing_block_used_values = box.is_viewport() ? nullptr : &get(*box.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();
new_used_values->set_node(const_cast<NodeWithStyleAndBoxModelMetrics&>(box), containing_block_used_values);
const_cast<LayoutState*>(this)->used_values_per_layout_node.set(&box, move(new_used_values));
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: 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
static void measure_scrollable_overflow(LayoutState const& state, Box const& box, CSSPixels& bottom_edge, CSSPixels& right_edge)
{
auto const* maybe_box_state = state.used_values_per_layout_node.get(&box).value_or(nullptr);
if (!maybe_box_state)
return;
auto const& box_state = *maybe_box_state;
auto scroll_container_border_box = CSSPixelRect {
box_state.offset.translated(-box_state.border_box_left(), -box_state.border_box_top()),
{ box_state.border_box_width(), box_state.border_box_height() }
};
bottom_edge = max(bottom_edge, scroll_container_border_box.bottom());
right_edge = max(right_edge, scroll_container_border_box.right());
if (box.children_are_inline()) {
if (!box_state.line_boxes.is_empty()) {
bottom_edge = max(bottom_edge, scroll_container_border_box.y() + box_state.line_boxes.last().bottom());
for (auto& line_box : box_state.line_boxes) {
if (line_box.fragments().is_empty())
continue;
right_edge = max(right_edge, scroll_container_border_box.x() + line_box.fragments().last().width());
}
}
} else {
// FIXME: Only check boxes for whom `box` is the containing block.
box.for_each_child_of_type<Box>([&](Box const& child) {
measure_scrollable_overflow(state, child, bottom_edge, right_edge);
return IterationDecision::Continue;
});
}
}
LibWeb: Rename FormattingState to LayoutState This seems a bit more descriptive (and also a bit shorter).
2022-07-16 23:30:32 +02:00
void LayoutState::commit()
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: 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: 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: 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& node = const_cast<NodeWithStyleAndBoxModelMetrics&>(used_values.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
// Transfer box model metrics.
LibWeb+WebContent: Forbid access to underlying type of CSSPixels Although DistinctNumeric, which is supposed to abstract the underlying type, was used to represent CSSPixels, we have a whole bunch of places in the layout code that assume CSSPixels::value() returns a floating-point type. This assumption makes it difficult to replace the underlying type in CSSPixels with a non-floating type. To make it easier to transition CSSPixels to fixed-point math, one step we can take is to prevent access to the underlying type using value() and instead use explicit conversions with the to_float(), to_double(), and to_int() methods.
2023-06-12 21:37:35 +03:00
node.box_model().inset = { used_values.inset_top, used_values.inset_right, used_values.inset_bottom, used_values.inset_left };
node.box_model().padding = { used_values.padding_top, used_values.padding_right, used_values.padding_bottom, used_values.padding_left };
node.box_model().border = { used_values.border_top, used_values.border_right, used_values.border_bottom, used_values.border_left };
node.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: 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
node.set_paintable(node.create_paintable());
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: 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
if (is<Layout::Box>(node)) {
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& box = static_cast<Layout::Box const&>(node);
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
auto& paintable_box = const_cast<Painting::PaintableBox&>(*box.paintable_box());
paintable_box.set_offset(used_values.offset);
paintable_box.set_content_size(used_values.content_width(), used_values.content_height());
paintable_box.set_containing_line_box_fragment(used_values.containing_line_box_fragment);
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: 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: 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
if (is<Layout::BlockContainer>(box)) {
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
for (auto& line_box : used_values.line_boxes) {
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
for (auto& fragment : line_box.fragments()) {
if (fragment.layout_node().is_text_node())
text_nodes.set(static_cast<Layout::TextNode*>(const_cast<Layout::Node*>(&fragment.layout_node())));
}
}
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
static_cast<Painting::PaintableWithLines&>(paintable_box).set_line_boxes(move(used_values.line_boxes));
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: 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: 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());
if (!box.is_scroll_container())
continue;
CSSPixels bottom_edge = 0;
CSSPixels right_edge = 0;
measure_scrollable_overflow(*this, box, bottom_edge, right_edge);
auto padding_box = box.paintable_box()->absolute_padding_box_rect();
if (bottom_edge > padding_box.height() || right_edge > padding_box.width()) {
Painting::PaintableBox::OverflowData overflow_data;
overflow_data.scrollable_overflow_rect = padding_box;
overflow_data.scrollable_overflow_rect.set_size(right_edge, bottom_edge);
const_cast<Painting::PaintableBox&>(*box.paintable_box()).set_overflow_data(overflow_data);
}
}
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
for (auto* text_node : text_nodes)
text_node->set_paintable(text_node->create_paintable());
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: 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
void LayoutState::UsedValues::set_node(NodeWithStyleAndBoxModelMetrics& node, UsedValues const* containing_block_used_values)
{
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) {
border_and_padding = CSSPixels(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: 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
+ CSSPixels(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 {
border_and_padding = CSSPixels(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: 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
+ CSSPixels(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;
auto containing_block_size_as_length = width
? CSS::Length::make_px(containing_block_used_values->content_width())
: CSS::Length::make_px(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: Make CSSPixels and Length use 64-bit (double) floating point This fixes a plethora of rounding problems on many websites. In the future, we may want to replace this with fixed-point arithmetic (bug #18566) for performance (and consistency with other engines), but in the meantime this makes the web look a bit better. :^) There's a lot more things that could be converted to doubles, which would reduce the amount of casting necessary in this patch. We can do that incrementally, however.
2023-05-24 10:50:57 +02:00
resolved_definite_size = adjust_for_box_sizing(containing_block_size * static_cast<double>(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+WebContent: Forbid access to underlying type of CSSPixels Although DistinctNumeric, which is supposed to abstract the underlying type, was used to represent CSSPixels, we have a whole bunch of places in the layout code that assume CSSPixels::value() returns a floating-point type. This assumption makes it difficult to replace the underlying type in CSSPixels with a non-floating type. To make it easier to transition CSSPixels to fixed-point math, one step we can take is to prevent access to the underlying type using value() and instead use explicit conversions with the to_float(), to_double(), and to_int() methods.
2023-06-12 21:37:35 +03:00
VERIFY(isfinite(width.to_double()));
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+WebContent: Forbid access to underlying type of CSSPixels Although DistinctNumeric, which is supposed to abstract the underlying type, was used to represent CSSPixels, we have a whole bunch of places in the layout code that assume CSSPixels::value() returns a floating-point type. This assumption makes it difficult to replace the underlying type in CSSPixels with a non-floating type. To make it easier to transition CSSPixels to fixed-point math, one step we can take is to prevent access to the underlying type using value() and instead use explicit conversions with the to_float(), to_double(), and to_int() methods.
2023-06-12 21:37:35 +03:00
VERIFY(isfinite(height.to_double()));
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: Fix table width algorithm when available space is a constraint Handle available space more carefully when computing a table width, in order to avoid creating a definite infinite width when available space width is max-content, as it's the case in calculate_max_content_width. The constraint is thus correctly propagated by the time we cache the computed value, which was previously rejected by the hash function due to being definite but infinite instead of max-content.
2023-06-11 12:04:01 +00:00
void LayoutState::UsedValues::set_min_content_width()
{
width_constraint = SizeConstraint::MinContent;
m_content_width = 0;
m_has_definite_height = false;
}
void LayoutState::UsedValues::set_max_content_width()
{
width_constraint = SizeConstraint::MaxContent;
m_content_width = INFINITY;
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