Right now, there's a huge amount of complexity in T{Node,Element,Document} and friends because of the lifetime parameter.
Before I started generalizing this code for use by Gecko, these wrappers were plain structs. They had (and still have) a phantom lifetime associated with them to prevent references to DOM nodes from leaking past the end of restyle, when they might be invalidated by a GC.
When I generalized them, I decided to put the lifetime on the trait as well, since there are some situations where the lifetime is, in fact, necessary. Specifically, they are necessary for the compiler to understand that all the things borrowed from all the nodes and elements and so on have the same lifetime (the lifetime of the restyle), rather than the lifetime of whichever particular element or node pointer the value was borrowed from. This come up in situations where we do |let el = node.as_element()| or |let n = el.as_node()| and then borrow something from the result. The compiler thinks the borrow lifetime is that of |el| or |n|, when it's actually longer.
In practice though, I think the style and layout algorithms we use don't run into this issue much, and we can hack around it where it comes up. So I think we should remove the lifetimes from the traits, which will let us aggregate the embedding-provided traits together onto a single meta-trait and significantly simplify the code.
Source-Repo: https://github.com/servo/servo
Source-Revision: aea8d8959dcb157a8cc381f1403246ce8ca1ca00
Flat display lists were a 2x regression on the spheres demo. This patch series fixes that.
See the individual commits for more details.
r? @mrobinson
Source-Repo: https://github.com/servo/servo
Source-Revision: 55fc48e4c46917a0f036d0054fac296bb5719434
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.
Source-Repo: https://github.com/servo/servo
Source-Revision: 62814f7cb486bc267a796b7ce58c51d59240fad0
This code dates back to the time when absolutely positioned flows were
ignored by all of their ancestors up to the containing block. This
hasn't been true for at least a year.
Closes#9306.
Closes#9309.
Is a partial fix for #9308.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: 4755cc5c6211e845fc8081cb3c8a67b4bdbea5cc
The LayerType enum is only used in gfx_traits and layout, so it
shouldn't be defined in msg. Move the definition to gfx_traits
instead.
Fixes#9220
Source-Repo: https://github.com/servo/servo
Source-Revision: d3889b4be43eb4d637f2d1ac5d021603653601eb
This gets us to where we need to be in order to write a Gecko implementation of the layout wrapper and have things Just Work.
Note that this is somewhat more than we need for just running the style system. But there wasn't a clean place to cut, and I thought it was a good idea to just do a complete job on it now, which may save us effort and mismatches in the long run.
Source-Repo: https://github.com/servo/servo
Source-Revision: 1f732cfbb404bfd96c3ed3f71c4b9900b7ffbba2
Use the PrintTree utility to improve the readability of flow tree
dumps. Blocks and fragments are now split over two dump levels, because
otherwise they are impenetrable. Also start printing the restyle damage of
fragments.
Source-Repo: https://github.com/servo/servo
Source-Revision: a2330f494316926dca9f64431d8357a093143d7d
Always produce a DisplayList when processing nodes for display list
construction. StackingContexts are now added to the positioned content
section of DisplayLists. This makes the code a bit simpler and opens up
the possibility of producing a StackingContext in another section of
the DisplayList. This doesn't change behavior, but is a cleanup
prerequisite for proper inline stacking context support.
Source-Repo: https://github.com/servo/servo
Source-Revision: da25b8c848886d2fc875008de5adcaf13d7c9e99
This flag is no longer necessary, because stacking contexts can now
create layers lazily for content that needs to be stacked above a
layer. This should reduce the number of layers on pages, hopefully
reducing overdraw.
Source-Repo: https://github.com/servo/servo
Source-Revision: acc0bf68736d6e4aee2e370bf91fc2465415aa6e
Also include absolutely positioned elements in the overflow rect calculation.
Fixes#7797.
Source-Repo: https://github.com/servo/servo
Source-Revision: ca56ebbb09f3c258d10e7a7fa276d42fe258d893
Sometimes positioned content needs to be layered on top of stacking
contexts. The layer synthesis code can do this, but the current design
prevents it because stacking contexts are stored in a separate struct
member. In order to preserve tree order, mix stacking contexts into the
positioned content list, by adding a new StackingContextClass
DisplayItem. Such items do not have a base DisplayItem.
In some ways this simplifies the code, because we no longer have to
have a separate code path in the StackingContextLayerCreator.
Source-Repo: https://github.com/servo/servo
Source-Revision: 86e3add8fdc35fc6980bb63695781925607437b8
After all these changes are applied, Hacker News and GitHub only repaint and reflow nodes that actually have hover styles applied when the mouse moves over them.
r? @mbrubeck
cc @bholley
Source-Repo: https://github.com/servo/servo
Source-Revision: 36c5dd4c8c543ed6767fe9dd367281b292d68dba
This adds -servo-left and -servo-right to complement -servo-center.
~~This intentionally doesn't try to address issue #7301.~~ Commit added to address #7301.
Source-Repo: https://github.com/servo/servo
Source-Revision: ab42ca42967354cba08d1dca83aa99a637bd7a6b
This is a direct extract from my abandoned PR for a lint (#7546), along with some rather clumsy modifications (only on `components/script/dom/mod.rs` and `components/style/lib.rs`), because I had to sort some of the files again to make peace with tidy, which hasn't been educated about sorting yet!
Source-Repo: https://github.com/servo/servo
Source-Revision: a7208869f2903e36f9b2f540b55b50283d7df466
Currently pseudo-elements, like the fragments created for ::before and
::after, with layers will have the same LayerId as the body of their
owning fragments. Instead all LayerIds should be unique.
Fixes#2010.
Source-Repo: https://github.com/servo/servo
Source-Revision: cf13e806fe2f4cf5ad5f30efd16d7bd3f501f8b3
StackingContexts that should be painted on top of StackingContexts that
are already layerized should automatically get their own layer. This
will ensure proper painting order.
Source-Repo: https://github.com/servo/servo
Source-Revision: c0381c732569b9abe6282c6c750533bc271a2019
Elided almost all the lifetimes and removed needless returns. Mostly done by sed + manual fixes.
r? @nox
Source-Repo: https://github.com/servo/servo
Source-Revision: c2c2646d37614ece5869af861993c3d619f6e003
Improves the position of the down arrows on google.com SERPs.
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: e46499a5dfd9189fc439c228d9a5fe23dfec0d7d
This necessitated changing overflow to be calculated by the parent flow
if relatively positioned children are present. That is because the
overflow regions cannot be calculated without knowing relative offsets,
which themselves cannot be calculated without knowing the parent size
(because of percentages). To accomplish this without sacrificing
parallelism in the non-relative case, this patch splits overflow into
"early" and "late" computation. Late overflow computation cannot be
parallelized across children, while early overflow computation can.
Makes the "Apple Music" text show up over the full-bleed promotional
background on apple.com.
r? @SimonSapin -- would appreciate a look over the iframe test case that was changed.
Source-Repo: https://github.com/servo/servo
Source-Revision: dcaf66397a06246b9b4fdca3a10af1508a11f1e8
This is #7154 with two additional commits (that I did rather than ask @zentner-kyle to do it because it was a bit tricky.)
r? @pcwalton for the last two commit
r=me+pcwalton in #7154 for earlier commits.
Source-Repo: https://github.com/servo/servo
Source-Revision: 5e83a3f0a3bab226cca849ab33fa3322ef71813d
and `for foo in bar.iter_mut(), and for foo in bar.into_iter()
(continuation of #7197)
Source-Repo: https://github.com/servo/servo
Source-Revision: 0d6d6a05009606dfbbfc9765d7dc2c745c18f6a5
Several issues are addressed in this commit:
* Inline flows now bubble up their absolute descendants instead of
making the inline flow the containing block for them. (In the future,
we will need to make the inline flow *sometimes* be the containing
block for them, but for now it improves sites to unconditionally
bubble up.)
* Fragments now look at their inline fragment context to determine
whether they are positioned.
* Inline flows now push the stacking-relative position of the absolute
containing block down to their inline-block fragments.
* Inline absolute hypothetical fragments can be containing blocks.
* Fixes the logic in
`containing_block_range_for_flow_surrounding_fragment_at_index`. The
condition to determine whether fragments are positioned was inverted!
* `Descendants`/`AbsDescendants` has been refactored in order to become
more friendly to inline absolute containing blocks in the future.
Improves the inline position of the green drop-down arrow in the Google
SERPs. (The block position is still wrong.)
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: d654841288ad6c7d4f8d7da3c68d04ef7df2c241
Expands on the work by @wilmoz and cleans up the existing errors. Closes#7180. Closes#7111.
Source-Repo: https://github.com/servo/servo
Source-Revision: e74825f9fde8e222f4ba9bb24b2c2a3864c73e5f
The failing `float-applies-to-*` CSS 2.1 tests never really should have
been passing in the first place; they depend on floats inside
fixed-layout tables working properly, which they don't.
Closes#6078.
Closes#6709.
Closes#6858.
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: 1ddef2997abf51716835017225b282f8a9077cce
There are some bad module-level doc comments in `flow.rs` which has directly affected [Servo's docs](http://doc.servo.org/layout/flow/index.html) and so, this fixes that. Oh, and #6728 is having a hard time getting closed and so I've also removed the `FIXME` comment related to it.
Source-Repo: https://github.com/servo/servo
Source-Revision: ae3aadd6567e15b5fb4da6c85fc4cdba9fcc2eb2
It's not possible to correctly determine during the css cascade whether the container height
is explicitly specified. Additionally, the spec https://drafts.csswg.org/css2/visudet.html#the-height-property says this should affect the *used* height, rather than the computed height.
This significantly improves the layout in #6643.
Source-Repo: https://github.com/servo/servo
Source-Revision: 028707f5cd3263fd1476669207f67d5b9d5d4806
