It is possible for a PaintTask to start exiting soon after sending new
buffers to the compositor. In that case, the compositor should return
the now unnecessary buffers to the PaintTask so that it can properly
free them.
To accomplish this, the compositor now keeps a hash map of paint task
channels per pipeline id. When a PaintTask exists, the constellation
informs the compositor that it can forget about it. Additionally, the
PaintTask should not wait for any buffers when the engine is doing a
complete shutdown. In that case, the compositor is already halted and
has simply let all buffers leak. We pipe through the shutdown type when
destroying the pipeline to make this decision.
Fixes#2641.
Source-Repo: https://github.com/servo/servo
Source-Revision: a31acffb0405b2c38b39c39c6d552f2ba79b6326
`str::to_string()` goes through a `Formatter`, `str::into_string()` is a direct copy and is apparently 5× faster.
This is a rebase of the boring and bitrot-prone parts of #4366.
Source-Repo: https://github.com/servo/servo
Source-Revision: 9857ea26cb9ee262654bee97322dbbf373486bff
Together these improve a large number of sites: GitHub, Reddit, Wikipedia, etc.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: 63a7742d834e9ed44421baa3ce218a5eabce58bf
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 patch provides some of the groundwork for column spans greater than
1. It implements the column-span CSS property as well as the
corresponding colspan attribute; although the former is not
well-specified outside of CSS multi-column layout, INTRINSIC refers to
it. Although width is distributed to spanning columns, they do not yet
contribute minimum and preferred widths; this will be implemented in a
follow-up.
The parsing for the legacy bgcolor and border attributes is
implemented according to the WHATWG HTML specification.
Additionally, this patch cleans up some miscellaneous formatting issues,
refactors layout/css somewhat to eliminate needless levels of
indirection, and cleans up the handling of table rowgroups.
New Hacker News screenshot: http://i.imgur.com/hnl2a7E.png
Source-Repo: https://github.com/servo/servo
Source-Revision: 8e31e5f98747e4b42dafcc4b076fac46aeb09310
This fixes race conditions whereby layout and script could be running
simultaneously.
r? @jdm
cc @cgaebel
Source-Repo: https://github.com/servo/servo
Source-Revision: 5f2684d2f81046abd7548fb22d996d1e506a104a
#4275
* This changeset rename "render"/"rendering" to "paint"/"painting" under `components/`.
* This does not rename words which are used as general browser's working.
* So this doesn't change `reftest.rs`.
Source-Repo: https://github.com/servo/servo
Source-Revision: 0b486b12109ab765ecee4cbcc684e5d99e8ad5ad
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 adds the infrastructure necessary to support stacking contexts that
are not containing blocks for absolutely-positioned elements. Our
infrastructure did not support that before. This minor revamp actually
ended up simplifying the logic around display list building and
stacking-relative position computation for absolutely-positioned flows,
which was nice.
This will need this PR: https://github.com/servo/rust-azure/pull/112 I have not updated the Cargo.lock file yet because I want the merge commit.
r? @glennw
f? @SimonSapin
Source-Repo: https://github.com/servo/servo
Source-Revision: 68c90e27970808bddcb8c8a4e782bd4405e67a5c
This implements the scheme described here:
https://groups.google.com/forum/#!topic/mozilla.dev.servo/sZVPSfPVfkg
This commit changes Servo to generate one display list per stacking
context instead of one display list per layer. This is purely a
refactoring; there are no functional changes. Performance is essentially
the same as before. However, there should be numerous future benefits
that this is intended to allow for:
* It makes the code simpler to understand because the "new layer needed"
vs. "no new layer needed" code paths are more consolidated.
* It makes it easy to support CSS properties that did not fit into our
previous flat display list model (without unconditionally layerizing
them):
o `opacity` should be easy to support because the stacking context
provides the higher-level grouping of display items to which opacity
is to be applied.
o `transform` can be easily supported because the stacking context
provides a place to stash the transformation matrix. This has the side
benefit of nicely separating the transformation matrix from the
clipping regions.
* The `flatten` logic is now O(1) instead of O(n) and now only needs to
be invoked for pseudo-stacking contexts (right now: just floats),
instead of for every stacking context.
* Layers are now a proper tree instead of a flat list as far as layout
is concerned, bringing us closer to a production-quality
compositing/layers framework.
* This commit opens the door to incremental display list construction at
the level of stacking contexts.
Future performance improvements could come from optimizing allocation of
display list items, and, of course, incremental display list
construction.
r? @glennw
f? @mrobinson @cgaebel
Source-Repo: https://github.com/servo/servo
Source-Revision: 397d8138e7b27541faf03d9635d7648416da4a75
Instead of creating a display list for the entire page, only create one
for an area that expands around the viewport. On my machine this makes
incremental layout of http://timecube.com 50% faster.
Source-Repo: https://github.com/servo/servo
Source-Revision: 26045d7fcbab8851fbefe2851cd904203f8fd8dd
Instead of looking at the display tree, have ContentBox(es)Query consult
the flow tree. This allow optimizing away parts of the display tree
later. To do this we need to be more careful about how we send reflow
requests, only querying the flow tree when possible.
Fixes#3790.
Source-Repo: https://github.com/servo/servo
Source-Revision: c9089c45c4b7d40419233b48a192d85a8ad71c99
This is the last PR and most of the work for the maze solver and RoboHornet.
r? @glennw
cc @cgaebel
Source-Repo: https://github.com/servo/servo
Source-Revision: 035ff19e4a5995989c5fd34928af2a6690bb8062
These should have no effect on functionality.
r? @metajack
Source-Repo: https://github.com/servo/servo
Source-Revision: 4bdd9a5ec02526b9a407b23dcbf95cc570e6fa56
Currently, both restyle/flow construction _and_ reflow are skipped
during resize. Reflow should not be in that list. This patch fixes
that.
Source-Repo: https://github.com/servo/servo
Source-Revision: 3b6e035d0d5e4055adfdc396e322fab82759fe9e
This is a grab bag of performance improvements that significantly improve style recalculation, layout, and painting on a few static pages.
Let me know if you'd like me to split this PR up.
r? @glennw
Source-Repo: https://github.com/servo/servo
Source-Revision: 156ca98236a57ee52ff5b68741bc7783ba073612
This also enables incremental reflow by default. \o/
r? @pcwalton
Source-Repo: https://github.com/servo/servo
Source-Revision: f6941b35e3b945f4a6dcd2cf03daa345ad2bcaed
The flow tree is currently dumped for debugging purposes early on in
the flow process, so many values are still zero. If we wait to dump it
until later, the output will more accurately reflect the real flow tree.
Source-Repo: https://github.com/servo/servo
Source-Revision: 3906cecd16b62445581e5af930680dd3f5ff66eb
This also adds some extra debugging infrastructure which I found useful tracking
this bug down. A regression in the br reftests is also uncovered by this patch,
which I'll work on fixing next.
EDIT: nevermind. no regression, I just tested that before a rebase.
r? @pcwalton
Source-Repo: https://github.com/servo/servo
Source-Revision: b86344b697f814b982e52f4a72c26d58c915c37b
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
This also hides the not-yet-working parts of incremental reflow behind a runtime
flag. As I get the failing reftests passing, I'll send pull requests for them one
by one.
Source-Repo: https://github.com/servo/servo
Source-Revision: 56989b8dec4aa95a3b484d45f15b23f9b3daaf13
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
