1
Fork 0
mirror of https://github.com/RGBCube/serenity synced 2025-05-22 03:25:07 +00:00
Commit graph

21 commits

Author SHA1 Message Date
Andreas Kling
64959a8504 LibWeb: Express intrinsic size layout via size constraints
Previously, we had three layout modes:

- Normal:
    - Everything uses the computed values from CSS.

- MinContent:
    - Containing blocks act as if they have 0 width.
    - All line breaking opportunities are taken.

- MaxContent:
    - Containing blocks act as if they have infinite width.
    - Only forced line breaks are accepted.

The above was based on a set of misunderstandings of CSS sizing.
A major problem with the above was that *all* containing blocks
behaved differently during intrinsic size layout, not just the
relevant one.

With this patch there are only two layout modes:

- Normal:
    - Everything uses the computed values from CSS.

- IntrinsicSizeDetermination:
    - One or more boxes have size constraints applied.

There are two size constraints per layout box, set here:

- FormattingState::NodeState::width_constraint
- FormattingState::NodeState::height_constraint

They are of type SizeConstraint and can be one of None, MinContent,
or MaxContent. The default is None.

When performing an IntrinsicSizeDetermination layout, we now assign
a size constraint to the box we're trying to determine the intrinsic
size of, which is then honored by using two new helpers to query
the dimensions of containing blocks:

- FormattingContext::containing_block_width_for(Box)
- FormattingContext::containing_block_height_for(Box)

If there's a relevant constraint in effect on the Box, the size of
its containing block is adjusted accordingly.

This is essentially an implementation of the "available space"
constraints from CSS-SIZING-3. I'm sure some things will break from
this, and we'll have to deal with that separately.

Spec: https://drafts.csswg.org/css-sizing-3/#available
2022-07-11 18:57:45 +02:00
Andreas Kling
4f6fc3d3a6 LibWeb: Only perform the requested form of intrinsic size calculation
Before, querying any of the four intrinsic sizes would cause us to
calculate all of them (the four being min-content width/height, and
max-content width/height).

Now, the helper functions only calculate the specific intrinsic size
requested. It's then cached at the root formatting context level,
so that it's never calculated twice within the same layout pass.
2022-07-11 18:57:44 +02:00
Andreas Kling
83a6be593c LibWeb: Add a 1-entry lookup cache to FormattingState
This makes repeated lookups of the state for the same box much faster
by bypassing the HashMap.
2022-07-06 20:31:22 +02:00
Andreas Kling
d2b7d2440f LibWeb: Cache flex item main sizes to avoid relayout during same cycle
This makes twitter.com actually load & render (although not very well.)
2022-07-06 00:22:42 +02:00
Andreas Kling
fe908e7db2 LibWeb: Rename "offset" in box model metrics to "inset"
The CSS Positioned Layout spec refers to the top/left/bottom/right
properties as "inset" properties, so let's use the same terminology.
2022-03-26 17:31:01 +01:00
Andreas Kling
40af665a49 LibWeb: Add margin box helpers to Layout::FormattingState 2022-03-24 18:14:01 +01:00
Andreas Kling
d3932b5880 LibWeb: Give FormattingState a reference to its root state
FormattingStates can have parents, in case we're performing nested
layouts to determine something's intrinsic size. In those cases, it will
soon be useful to find the outermost (root) state.
2022-03-18 15:18:48 +01:00
Andreas Kling
515db5fc1b 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-13 00:04:51 +01:00
Andreas Kling
3f2b17f602 LibWeb: Add functions for calculating intrinsic sizes of a Layout::Box
FormattingContext can now calculate the intrinsic sizes (min-content and
max-content in both axes) for a given Layout::Box.

This is a rather expensive operation, as it necessitates performing two
throwaway layouts of the subtree rooted at the box. Fortunately, we can
cache the results of these calculations, as intrinsic sizes don't change
based on other context around the box. They are intrinsic after all. :^)
2022-03-13 00:04:51 +01:00
Andreas Kling
ba606d9057 LibWeb: Move PaintingBox to its own .cpp and .h files 2022-03-11 00:21:49 +01:00
Andreas Kling
053766d79c 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-11 00:21:49 +01:00
Andreas Kling
f6497b64ac LibWeb: Rename Painting::Box => Paintable
Calling this "Box" made it very confusing to look at code that used both
Layout::Box and Painting::Box. Let's try calling it Paintable instead.
2022-03-11 00:21:49 +01:00
Andreas Kling
a4d51b3dc2 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-11 00:21:49 +01:00
Andreas Kling
f8aa0c144f LibWeb: Store box's containing line box fragment in FormattingState
Layout should not change any properties of a box until the moment a
FormattingState is committed.
2022-02-28 14:17:44 +01:00
Andreas Kling
aa72ebf7aa 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 14:17:44 +01:00
Andreas Kling
19954dfdf8 LibWeb: Add FormattingState::clone()
This makes a deep copy of a FormattingState.
2022-02-28 14:17:44 +01:00
Andreas Kling
1d05823810 LibWeb: Store Layout::Box overflow data in Optional instead of OwnPtr 2022-02-28 14:17:44 +01:00
Andreas Kling
db5bf6e64c LibWeb: Rename FormattingState::ensure() -> get_mutable()
This makes it much more obvious what the difference between get() and
get_mutable() is.
2022-02-21 18:35:12 +01:00
Andreas Kling
2615728d6b LibWeb: Store overflow data in the FormattingState 2022-02-21 18:35:12 +01:00
Andreas Kling
c9700e100e 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-21 18:35:12 +01:00
Andreas Kling
561612f219 LibWeb: Add Layout::FormattingState
The purpose of this new object will be to keep track of various states
during an ongoing layout.

Until now, we've been updating layout tree nodes as we go during layout,
which adds an invisible layer of implicit serialization to the whole
layout system.

My idea with FormattingState is that running layout will produce a
result entirely contained within the FormattingState object. At the end
of layout, it can then be applied to the layout tree, or simply queried
for some metrics we were trying to determine.

When doing subtree layouts to determine intrinsic sizes, we will
eventually be able to clone the current FormattingState, and run the
subtree layout in isolation, opening up opportunities for parallelism.

This first patch doesn't go very far though, it merely adds the object
as a skeleton class, and makes sure the root BFC has one. :^)
2022-02-21 18:35:12 +01:00