| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
when calculating overflow areas.
This only works for simple translations and similar, but I want Patrick to
validate my approach.
|
| |
|
| |
|
|
|
|
| |
This also fixes Undefined Behavior in build_display_list_for_subtree.
|
|
|
|
| |
This fixes #11185.
|
|
|
|
|
|
|
| |
We don't really need two levels of abstraction for every element in the
DisplayList. This simplifies the complexity of the data structure in
preparation for providing documentation and properly handling scrolling
roots.
|
|
|
|
| |
Fixes #10625
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
bottom-up pass.
Right now, the only reason that overflow calculation works is that we
rely on script inducing extra reflows that are sent for display. This
was preventing #10021 from landing.
This change regresses layout performance by about 1% in my tests.
Fixes #7797 properly.
|
| |
|
|
|
|
| |
This eliminates a lot of allocations and O(n^2) behavior.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
The incorrect naming here was bugging me - the dom traversal has both pre- and post-order
processing steps.
|
| |
|
|
|
|
|
|
| |
I forgot to do this along with the parallel case. Ideally I'd merge this patch
into that one, but then I'd need to rebase it over the LayoutContext patch,
which would be a pain.
|
| |
|
|
|
|
| |
LayoutContext.
|
|
|
|
| |
themselves.
|
| |
|
|
|
|
|
|
|
| |
There wasn't a good way to split this up, unfortunately.
With this change, the only remaining usage of the Servo-specific structures is
in layout_task, where the root node is received from the script task. \o/
|
|
|
|
|
| |
The next step will be to remote the Servo-specificity of the layout code we want
to share by making it operate generically on Layout*.
|
| |
|
|
|
|
|
| |
All the existing code still uses the concrete implementations, so this
shouldn't impact the generated code at all.
|
|
|
|
|
|
| |
Also include absolutely positioned elements in the overflow rect calculation.
Fixes #7797.
|
|
|
|
| |
SharedLayoutContext.
|
| |
|
| |
|
|
|
|
| |
This merges import blocks that were reported by tidy as unmerged.
|
|
|
|
| |
Fixes scrolling on Twitter.
|
|
|
|
| |
See discussion in https://github.com/servo/servo/pull/7237
|
|
|
|
| |
See #6503.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
§ 12.3-12.5.
Only simple alphabetic and numeric counter styles are supported. (This
is most of them though.)
Although this PR adds a sequential pass to layout, I verified that on
pages that contain a reasonable number of ordered lists (Reddit
`/r/rust`), the time spent in generated content resolution is dwarfed by
the time spent in the parallelizable parts of layout. So I don't expect
this to negatively affect our parallelism expect perhaps in pathological
cases.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
through display list building.
The old `flow_origin` concept was ill-defined (sometimes the border box
plus the flow origin, sometimes including horizontal margins and
sometimes not, sometimes including relative position and sometimes not),
leading to brittleness and test failures. This commit reworks the logic
to always pass border box origins in during display list building.
|
|
|
|
|
| |
This was making `box-shadow` not show up in many cases, in particular,
but the effects were not limited to that.
|