Pointers to DOM nodes from layout could go stale if incremental reflow
does not correctly destroy dead nodes. Therefore, we ask the JavaScript
garbage collector to verify that each DOM node is indeed a valid pointer
before calling event handlers on it, and fail otherwise.
* add servo_util::task::{spawn_named,spawn_with_named} functions
* add name param for spawn_listener and spawn_conversation functions
this should resolve#1169
This will allow us to stop going to the DOM in order to handle iframe
sizing. Instead we can just store the pipeline and frame IDs of iframes
inside the flow tree itself.
This fixes the computation of restyle damage on `color-change-text.html`, which can be seen with `RUST_LOG=servo::layout::layout_task`.
However we can't prune the layout traversals yet, because we don't reuse `Flow` objects between reflows, so we have no old values to fall back to.
I think this used to work because `FlowContexts` (as they were called then) were stored in a DOM node's `LayoutData` and reused. But it's possible that it never really worked, and my testing when I landed the restyle damage code was insufficient (I didn't understand the layout code nearly as well back then).
r? @pcwalton
We don't reuse Flow objects between reflows, so we have no old values to fall
back to.
I think this used to work because FlowContexts (as they were called then) were
stored in a DOM node's LayoutData and reused. But it's possible that it never
really worked, and my testing when I landed the restyle damage code was
insufficient (I didn't understand the layout code nearly as well back then).
This reverts commit e8ffac13d7, reversing
changes made to db923feffe.
Reverting this change because FreeType is *not* thread safe. See the
documentation here:
http://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html
"In multi-threaded applications, make sure that the same FT_Library
object or any of its children doesn't get accessed in parallel."
We will need to use a `MutexArc` instead.
This replaces flow construction with a strict bottom-up tree traversal,
allowing for parallelism. Each step of the traversal creates a flow or
a `ConstructionItem`, similar to how Gecko works. {ib} splits are
handled by not creating `InlineFlow`s until the containing block is
reached.
This should be able to be incrementalized by storing the `Flow` from
layout to layout, and performing fixups during flow construction
and/or wiping containing blocks in a previous pass.
This an attempt to parallelize selector matching.
Approach
* Let the `match_subtree` spawn limited number of tasks.
* Each of them takes a list of nodes that is uniformly distributed
* And then each task does the selector matching for every single node in its list.
(Not sure if this is worthwhile for long term especially considering CSS optimizing techniques such as ancestor filter or style sharing)
Benchmark from my machine (LayoutSelectorMatchCategory) (intel i7 3.4GHz * 8, linux x86_64)
* src/test/demo.html
* original: 0.07ms
* parallel: 0.20ms
* perf-rainbow.html
* original: 485ms
* parallel: 245ms
* A test page with 15000 nodes and 3000 CSS selector(including inline style).
* original: 140ms
* parallel: 60ms
I started this in a [separate repository](https://github.com/SimonSapin/servo-style), and imported it with [git-subtree](https://github.com/git/git/blob/master/contrib/subtree/git-subtree.txt) into `servo/src/components/script/style` after some Rust minor upgrades.
I move this into the script crate because it’s gonna both need stuff there (the content tree, for selector matching) and be needed by stuff there (the HTML parser calls the CSS parser). As far as I know, we can not have circular dependencies between crates.
