In particular, this contains changes to qualify enums where rust will require it, and to stop using some features that will be removed.
Source-Repo: https://github.com/servo/servo
Source-Revision: ba8cf6b0e6145265f9472d4855f078d8b5943fe7
I'm not sure how we want to handle Linux cursors, and GLFW has no
ability to set cursors (short of disabling it and managing it yourself).
If you test this in the wild you will probably hit #4357 until that PR lands.
Source-Repo: https://github.com/servo/servo
Source-Revision: e2267e0a0749e27046ee8a26ba514cc6865e0345
This makes these parameters self-documenting.
This patch does not attempt to push those enums into the data
structures that feed calls to this function.
Fixes#4158.
Source-Repo: https://github.com/servo/servo
Source-Revision: bc7b5b35b44e82dadb35242e39b190b3d1fcba10
This patch switches FlowRefs to using the Deref and DerefMut traits, instead of
the custom `get` and `get_mut` functions.
Source-Repo: https://github.com/servo/servo
Source-Revision: 6a11ee89de82abae9d6607a6c2890692df5259eb
Now that DOM/Flow traversals have been refactored out, the `recalc_style_for_subtree`
function in `css/matching.rs` can be removed, in lieu of just running the standard
`recalc_style_for_node` and `construct_flows` traversals sequentially. Now we
no longer have the maintenance headache of duplicating selector matching logic
in two places! \o/
This passes reftests with both default arguments, and with `-y 1`.
r? @pcwalton
Source-Repo: https://github.com/servo/servo
Source-Revision: 7eaeaeeb217e7cbd083fe318863e7de4b9f38e2b
We push down clipping areas during absolute position calculation. This
makes display items into a flat list, improving cache locality. It
dramatically simplifies the code all around.
Because we need to push down clip rects even for absolutely-positioned
children of non-absolutely-positioned flows, this patch alters the
parallel traversal to compute absolute positions for
absolutely-positioned children at the same time it computes absolute
positions for other children. This doesn't seem to break anything either
in theory (since the overall order remains correct) or in practice. It
simplifies the parallel traversal code quite a bit.
See the relevant Gecko bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=615734
r? @mrobinson
Source-Repo: https://github.com/servo/servo
Source-Revision: fd70b366aeada7f8cb4b2457c04fd07f0ea9b143
stretching.
This preserves the usage of the Bloom filter throughout style recalc,
but the implementation is rewritten. Provides a 15% improvement on
Guardians of the Galaxy.
Source-Repo: https://github.com/servo/servo
Source-Revision: e048f3f940e124d45b43a53a850177c45907822d
This patch puts in the initial framework for incremental reflow. Nodes' styles
are no longer recalculated unless the node has changed.
I've been hacking on the general problem of incremental reflow for the past
couple weeks, and I've yet to get a full implementation that actually passes all
the reftests + wikipedia + cnn. Therefore, I'm going to try to land the different
parts of it one by one.
This patch only does incremental style recalc, without incremental flow
construction, inline-size bubbling, reflow, or display lists. Those will be coming
in that order as I finish them.
At least with this strategy, I can land a working version of incremental reflow,
even if not yet complete.
r? @pcwalton
Source-Repo: https://github.com/servo/servo
Source-Revision: 85b277655f07db1cb99c4d3dee93804735ed0470
Makes multiple `<br>` elements work, since those are implemented via
`before` pseudos.
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: 15b508ac10d0e98ba10474b6ab091017ae95804e
Although the computed `display` property of elements with `position:
absolute` is `block`, `position: absolute; display: inline` can still
behave differently from `position: absolute; display: block`. This is
because the hypothetical box for `position: absolute` can be at the
position it would have been if it had `display: inline`. CSS 2.1 §
10.3.7 describes this case in a parenthetical:
"The static-position containing block is the containing block of a
hypothetical box that would have been the first box of the element if
its specified 'position' value had been 'static' and its specified
'float' had been 'none'. (Note that due to the rules in section 9.7 this
hypothetical calculation might require also assuming a different
computed value for 'display'.)"
To handle this, I had to change both style computation and layout. For
the former, I added an internal property
`-servo-display-for-hypothetical-box`, which stores the `display` value
supplied by the author, before the computed value is calculated. Flow
construction now uses this value.
As for layout, implementing the proper behavior is tricky because the
position of an inline fragment in the inline direction cannot be
determined until height assignment, which is a parallelism hazard
because in parallel layout widths are computed before heights. However,
in this particular case we can avoid the parallelism hazard because the
inline direction of a hypothetical box only affects the layout if an
absolutely-positioned element is unconstrained in the inline direction.
Therefore, we can just lay out such absolutely-positioned elements with
a bogus inline position and fix it up once the true inline position of
the hypothetical box is computed. The name for this fix-up process is
"late computation of inline position" (and the corresponding fix-up for
the block position is called "late computation of block position").
This improves the header on /r/rust.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: f7d2fb6ff86afff7a5b674f751af9370a5a6b142
