layout: Rewrite display list building to be parallel and to handle
overflow correctly, and opportunistically lay out blocks in parallel
even if floats are present.
This series of commits fixes the `inline-height-test` in Acid2 by
implementing proper overflow as well as the inline "strut". (See CSS 2.1
§ 10.8.1.) It was accidentally working before because tables' descendant
flows were not being laid out properly.
Display list building is now parallel and is done by bubbling up display
items and layers from parent to child. Speedups of around 60%-70% are
observed on Wikipedia with a 4-core HyperThreaded Core i7. More
optimizations are possible; this is just a start.
To minimize the amount of data that needs to be bubbled up, as well as
to make proper handling of `overflow: hidden` clipping easier, the
`StackingContext` abstraction is now purely internal to the display
list. Instead of placing items into a stacking context directly, display
items are placed into display lists with an explicit `StackingLevel`
provided. The stacking level determines a display item's position within
the stacking context. When a stacking context is finished, it is
flattened with the the `flatten` method, which shuffles the display
items that make up the context into their proper order while handling
clipping properly.
r? @SimonSapin and/or @larsbergstrom
overflow correctly, and opportunistically lay out blocks in parallel
even if floats are present.
This commit fixes the `inline-height-test` in Acid2 by implementing
proper overflow as well as the inline "strut". (See CSS 2.1 § 10.8.1.)
Acid2 was accidentally being rendered properly before because tables'
descendant flows were not being laid out properly.
Display list building is now parallel and is done by bubbling up display
items and layers from parent to child. Speedups of around 60%-70% are
observed on Wikipedia with a 4-core HyperThreaded Core i7. More
optimizations are possible; this is just a start.
To minimize the amount of data that needs to be bubbled up, as well as
to make proper handling of `overflow: hidden` clipping easier, the
`StackingContext` abstraction is now purely internal to the display
list. That is, instead of placing items into a stacking context
directly, display items are placed into display lists alongside a
stacking level. When a stacking context is complete, it is flattened
with the the `flatten` method, which shuffles the display items that
make up the context into their proper order while handling clipping
properly.
layout: Re-enable parallel layout by removing all `RefCell` instances from `Flow`s; in the process, remove `InlineInfo` in favor of the range-based design that was originally planned and halfway implemented.
Now, the DOM tree structure for inline flows is reflected not by a
series of arrays but instead by a flat list of ranges into the list of
boxes. As part of this, the `border` and `padding` fields, which were
incorrect in the case of inlines and necessitated separate
`noncontent_inline_foo` methods, have been merged into a single
`border_padding` field that is always guaranteed to be correct after
width assignment, even for inlines.
r? @SimonSapin and/or @larsbergstrom
Closes#1280Closes#1926Closes#1999Closes#2013Closes#2018
from `Flow`s; in the process, remove `InlineInfo` in favor of the
range-based design that was originally planned and halfway implemented.
Now, the DOM tree structure for inline flows is reflected not by a
series of arrays but instead by a flat list of ranges into the list of
boxes. As part of this, the `border` and `padding` fields, which were
incorrect in the case of inlines and necessitated separate
`noncontent_inline_foo` methods, have been merged into a single
`border_padding` field that is always guaranteed to be correct after
width assignment, even for inlines.
Since the manifest is now checked in to the tree, we don't need html5lib unless we want to explicitly update the manifest.
I've added the `--update-manifest` argument to the make target (`export WPTARGS=--update-manifest;make check-wpt`) which triggers the update, installing dependencies if necessary.
Another attempt at the merginating of my long-dormant embedding work for #441
This adds the basics for the embedding crate: build rules and 1800+ lines of CEF types
r? @larsbergstrom
the embedding crate contains 1800+ lines of types from an external library, most
of which are not used or "rust"ically named. the former will change eventually,
but we have no control over the naming.
