Not yet ready for merge, but you can start reviewing.
Still need to fix linux and some make check code.
Source-Repo: https://github.com/servo/servo
Source-Revision: b2e7e67087370e30a310bb3673b074c97c19d548
--HG--
rename : servo/src/components/style/common_types.rs => servo/src/components/style/properties/common_types.rs
rename : servo/src/components/style/properties.rs.mako => servo/src/components/style/properties/mod.rs.mako
rename : servo/src/components/util/debug.rs => servo/src/components/util/debug_utils.rs
This simplifies inline.rs and makes things easier to understand.
I've also added some documentation for `Line`.
r? @pcwalton
Source-Repo: https://github.com/servo/servo
Source-Revision: 184d8b5bab2aa999280c6c3b7618428bb22b5205
I tried to make sure to keep 'box' where it made sense, and alter comments so they still make sense.
r? @pcwalton
Source-Repo: https://github.com/servo/servo
Source-Revision: 547ad2dc480c69798c80a25057ebc9d91ed79389
This isolates layout code from upcoming refactoring in properties.rs.mako.
Source-Repo: https://github.com/servo/servo
Source-Revision: 50c2af8ef19de31c4b41100f4278c937ced47c64
Before we had Vec<T>, Option<~[T]> was used as an optimization of ~[T] to avoid allocating for empty vectors when that was the common case. Vec<T> itself does this optimization, so there is no need for this anymore.
r? @larsbergstrom
Source-Repo: https://github.com/servo/servo
Source-Revision: 309c9db2ac313cb78760615e893b2723a380eace
We can't replace the ones in the `style` crate because some functions expect generic `SmallVec`s.
I also did some reorganisation of the `smallvec` macros.
cc @pcwalton
Source-Repo: https://github.com/servo/servo
Source-Revision: b6c785692645b22c8b6119cb28109e85e703e430
As described in #1764, this strategy uses the following properties:
* DOM members are `JS<T>` types. These cannot be used with being explicitly rooted, but they are required for compiler-derived trace hooks.
* Methods that take DOM type arguments receive `&[mut] JSRef<T>`. These are rooted value references that are cloneable but cannot escape.
* Methods that return DOM values use `Unrooted<T>`. These are values that may or may not be rooted elsewhere, but callers must root them in order to interact with them in any way. One unsoundness hole exists - `Unrooted` values must be rooted ASAP, or there exists the danger that JSAPI calls could be made that could cause the underlying JS value to be GCed.
* All methods are implemented on `JSRef<T>`, enforcing the requirement that all DOM values are rooted for the duration of a method call (with a few exceptions for layout-related code, which cannot root values and therefore interacts with `JS<T>` and `&T` values - this is safe under the assumption that layout code interacts with DOM nodes that are in the tree, therefore rooted, and does not run concurrently with content code)
Source-Repo: https://github.com/servo/servo
Source-Revision: 731e66ff132e41cdc49bc5324c0e15be19c46ec2
layout: Rewrite display list building to be parallel and to handle
overflow correctly, and opportunistically lay out blocks in parallel
even if floats are present.
This series of commits fixes the `inline-height-test` in Acid2 by
implementing proper overflow as well as the inline "strut". (See CSS 2.1
§ 10.8.1.) It was accidentally working before because tables' descendant
flows were not being laid out properly.
Display list building is now parallel and is done by bubbling up display
items and layers from parent to child. Speedups of around 60%-70% are
observed on Wikipedia with a 4-core HyperThreaded Core i7. More
optimizations are possible; this is just a start.
To minimize the amount of data that needs to be bubbled up, as well as
to make proper handling of `overflow: hidden` clipping easier, the
`StackingContext` abstraction is now purely internal to the display
list. Instead of placing items into a stacking context directly, display
items are placed into display lists with an explicit `StackingLevel`
provided. The stacking level determines a display item's position within
the stacking context. When a stacking context is finished, it is
flattened with the the `flatten` method, which shuffles the display
items that make up the context into their proper order while handling
clipping properly.
r? @SimonSapin and/or @larsbergstrom
Source-Repo: https://github.com/servo/servo
Source-Revision: 1a88996c0438212a4e77369515a243c9c24c4518
layout: Re-enable parallel layout by removing all `RefCell` instances from `Flow`s; in the process, remove `InlineInfo` in favor of the range-based design that was originally planned and halfway implemented.
Now, the DOM tree structure for inline flows is reflected not by a
series of arrays but instead by a flat list of ranges into the list of
boxes. As part of this, the `border` and `padding` fields, which were
incorrect in the case of inlines and necessitated separate
`noncontent_inline_foo` methods, have been merged into a single
`border_padding` field that is always guaranteed to be correct after
width assignment, even for inlines.
r? @SimonSapin and/or @larsbergstrom
Closes#1280Closes#1926Closes#1999Closes#2013Closes#2018
Source-Repo: https://github.com/servo/servo
Source-Revision: 1ab22d947008b90e01c565736d3d3953ad491648
r? @metajack
Note that all pending submodule PRs must be landed before this should be given r+.
Source-Repo: https://github.com/servo/servo
Source-Revision: 493aa2cdf30fb2ff5886c714030a20d714764b67
If <span> element has pseudo style, draw pseudo element.
Source-Repo: https://github.com/servo/servo
Source-Revision: 257e1c0130d6716178e2c61f1084b90fd2c94d7b
This is a rebase of #1548 on recent master.
There have been many changes since #1548 is first uploaded, so I'm creating new PR.
This PR includes:
- construction of table-* flows (table-wrapper, table-caption, table, table-rowgroup, table-row, table-cell)
- fixed-layout table calculation
- a part of anonymous table object implementation
[CSS 2.1, 17.2.1](http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes) (Step 1-1, 1-2, Step 2)
Source-Repo: https://github.com/servo/servo
Source-Revision: fd5e5cd18b41f0ce2b33fb97fb4e3d75ddbbbceb
For review only - don't approve yet (need to squash and land submodule updates first).
critic? @metajack
Source-Repo: https://github.com/servo/servo
Source-Revision: f7aa6e3d9b8bfcc0565624f1094241b3b8658bd8
+ Re-implement fixed positioning using the absolute positioning code.
+ Add reftests for absolute positioning and fixed positioning.
+ Refactor assign_widths in BlockFlow to isolate the calculation of
widths and margins.
+ Pass down details of the Containing Block for absolute and fixed flows
during layout. Use it to calculate the static position of absolute flows.
+ Defer calculation of absolute flow dimensions till we build the
display list.
This implements https://github.com/mozilla/servo/issues/1537 and https://github.com/mozilla/servo/issues/787
Source-Repo: https://github.com/servo/servo
Source-Revision: ada9224d0ef5b403562ebaaeb2e5f66729ffc589
Simple change. I hope I'm using github correctly; I'm not too familiar with the PR system. Fixes#1777.
Source-Repo: https://github.com/servo/servo
Source-Revision: 021d32368d569298da619041c9ffe262c91063e4
This rewrites the float context to avoid dynamic failures resulting from
`.clone()` misuse. It also renames the float context to the simpler
`Floats`. The new version is modeled on WebKit's `FloatingObjects`.
r? @kmcallister
Source-Repo: https://github.com/servo/servo
Source-Revision: 580c23f35bd7c43498d61fec04745cedabb8246a
cc @pradeep90 — This removes leaf sets and should be enough to get you started.
This series of patches combines various layout passes to eliminate the overhead involved with bottom-up passes. It also makes assign-widths and flow construction run in parallel. No raw layout code was touched (except in trivial ways); rather this just changes the way methods are invoked. So the overall level of code cleanliness should remain the same. In fact, this is a (slight) net loss in LOC, and should be an improvement in safety due to not having to ensure that the nodes in the leaf sets stay alive!
This was quite a nice speedup; we're now 38% faster than Blink sequentially for style recalc on the rainbow page and 2.56x faster with 4 cores. (The relatively low speedup is because the LRU cache hits perfectly on that page sequentially.)
There is a data race somewhere in the unsafe code I added, so *do not merge yet*.
Source-Repo: https://github.com/servo/servo
Source-Revision: da16e54243e256dee927f720ce6b9903b62ec14e
The specs currently have only Document; this may well change, but the split won't be along the lines we've implemented right now. In the meantime, this simplifies our code quite a bit.
Source-Repo: https://github.com/servo/servo
Source-Revision: 22760b6665c75f6908bcfd7cad4de111187ac6f7
Support for #1636
Now, we can see eyes in acid2.html :)
Source-Repo: https://github.com/servo/servo
Source-Revision: 1f90716bc10d9134a13ac41a97d217104247010f
... to characterdata
All other node's parent type names reflect the actual type of the parent. This change extends that convention to the indicated nodes.
closes#1594
Source-Repo: https://github.com/servo/servo
Source-Revision: a0b55b4c6cfacf3c9d59a07c8ee756c0dffad7f9
This series of patches implements style struct sharing as found in existing browser engines, as well as a bunch of related important optimizations. With them, we are faster than Blink, WebKit, and Gecko on the rainbow page for style recalc in sequential mode by at least 15%. Parallel gains are mixed—the rainbow page turns out to be a degenerate sequential case for the LRU cache used to track candidates for style sharing and so there is no improvement. For cases in which the cache is not hit, such as `perf-rainbow-hard.html`, we are around 25% slower than Blink sequentially, but have very large parallel wins so that we are around 2x faster at style recalc. (Note that parallel flow tree construction will improve this further.)
This patch series also fixes, as near as I can tell, some bugs related to ordering of properties that other properties depend on in selector matching.
r? @larsbergstrom
feedback? @SimonSapin (for selector matching changes)
feedback? @bzbarsky (for style sharing heuristics)
Source-Repo: https://github.com/servo/servo
Source-Revision: 425210b9b404ca769037879f9c2a01c63a0375c8
be needed.
33% win in flow construction on the rainbow page.
r? @larsbergstrom
Source-Repo: https://github.com/servo/servo
Source-Revision: 5a7d22c43775264359b8ddea8f60d237f5715593
5% perf win, and a net loss in lines of code.
r? @larsbergstrom
Source-Repo: https://github.com/servo/servo
Source-Revision: 1dbc73ea1c5ab395d03934024e3f1a773b357032
construction.
This will be very slow until we have the concurrent hash table, but we
might as well get it in.
r? @metajack
Source-Repo: https://github.com/servo/servo
Source-Revision: 6c2e48f04d83cb0491138d8cc8a5c81ebc160cc6
to be leaves.
60% improvement in flow tree construction time on the rainbow page.
r? @larsbergstrom
Source-Repo: https://github.com/servo/servo
Source-Revision: 9f6ab8ed7761edd218ac6e65e74cfb7aafca4cb2
implement inline border.
it gives same result in "src/test/html/test_inline_border.html" with chrome,firefox
r? @pcwalton
Source-Repo: https://github.com/servo/servo
Source-Revision: d944567b9a2a7e5757d3f7c681dd4d42c69c58da
infrastructure.
The work queue accepts abstract generic "work units", which in this case
are layout operations. The same speedups have been observed.
r? @larsbergstrom
Source-Repo: https://github.com/servo/servo
Source-Revision: 5ca55bb996b2a447ff05c09aa0a8d87e80e75ee5
