Add a `LogicalMargin::start_end()` method that receives a `Direction'
parameter. This is useful for some layout that is symmetric in inline
and block directions, like flexbox.
Set the flag of the fragment of children in a flex container according
to the direction of the container. The mark is done on the fragment
because flex item enstablish a stacking context when its z-index is
non-zero ,despite its `position' property.
This is a step in disassociating scrolling areas from stacking
contexts. Now scroll areas are defined by unique ids, which means that
in the future stacking context will be able to contain more than one.
Simplify the way that stacking contexts are collected. Instead of
passing the StackingContextId down the tree, pass the parent
StackingContext itself. This will allow future patches to get more
information about the parent stacking context (such as location).
Also remove the return value of collect_stacking_contexts, which was
unused.
Fix the currently logic that a item will freeze if it should
grow(shrink) and its basesize is less(more) than its min(max) size. Also
fix the divide by zero error when an item should shrink but it has zero
length and zero min size.
The 'box_sizing_boundary()' method return the border_padding width in
certain direction if fragment has property 'box-sizing: border-box'. The
'border_padding' field should be initialized before.
Iterate over the items, create lines from them, resolve flex lengths
against them, set their inline size and margin lengths, and align them
according to 'justify-content', 'align-content' and 'align-self'.
As the flexbox spec change in May 2016, the absolutely positioned
children painting order no longer follow the `order` property, thus we
can simply filter them out.
Also sort items by the order field of 'FlexItem', no longer do two
vtable lookups in each compare.
These 'is_wrappable' flag can be used to determine if a flex flow can be
multi-line. The 'is_reverse' flag is replaced by 'main_reverse' and
'cross_reverse' since flex flow can go reverse individually in main and
cross direction.
Extend fields of `FlexItem` struct with values that are necessary to
resolve flexible lengths, and the 'order' property. Add other methods
for size computing to make the code more modular.
WebRender.
This happens asynchronously, just as it does in non-WebRender mode.
This functionality is a prerequisite for doing proper display-list-based
hit testing in WebRender, since it moves the scroll offsets into Servo
(and, specifically, into the script thread, enabling iframe event
forwarding) instead of keeping them private to WebRender.
Requires servo/webrender_traits#55 and servo/webrender#277.
Partially addresses #11108.
This is the first part of #10185. More to follow. I have built this locally with both servo and geckolib without errors; let's see if it succeeds on all platforms as well.
speculation code.
The old code tried to do the speculation as a single bottom-up pass
after intrinsic inline-size calculation, which was unable to handle
cases like this:
<div>
<div style="float: left">Foo</div>
</div>
<div>
<div style="overflow: hidden">Bar</div>
</div>
No single bottom-up pass could possibly handle this case, because the
inline-size of the float flowing out of the "Foo" block could never make
it down to the "Bar" block, where it is needed for speculation.
On the pages I tried, this regresses layout performance by 1%-2%.
I first noticed this breaking some pages, like the Google SERPs, several
months ago.
`memmove` was showing up high in the profile when concatenating and
shorting display lists. This change drastically reduces the `memmove`
cost in exchange for some minor additional allocation cost.
Instead of producing a tree of stacking contexts, display list
generation now produces a flat list of display items and a tree of
stacking contexts. This will eventually allow display list construction
to produce and modify WebRender vertex buffers directly, removing the
overhead of display list conversion. This change also moves
layerization of the display list to the paint thread, since it isn't
currently useful for WebRender.
To accomplish this, display list generation now takes three passes of
the flow tree:
1. Calculation of absolute positions.
2. Collection of a tree of stacking contexts.
3. Creation of a list of display items.
After collection of display items, they are sorted based upon the index
of their parent stacking contexts and their position in CSS 2.1
Appendeix E stacking order.
This is a big change, but it actually simplifies display list generation.
