aboutsummaryrefslogtreecommitdiffstats
path: root/components/layout/fragment.rs
diff options
context:
space:
mode:
authorPatrick Walton <pcwalton@mimiga.net>2014-11-11 22:07:39 -0800
committerPatrick Walton <pcwalton@mimiga.net>2014-11-14 17:31:15 -0800
commita4a9a46a87221aaa40e145602a9211e5542753a0 (patch)
tree104a88e5e9b5eb28a093127480d72ea05b52e4cc /components/layout/fragment.rs
parent0ab70dd539798022ebadd07fb799096809f14d3f (diff)
downloadservo-a4a9a46a87221aaa40e145602a9211e5542753a0.tar.gz
servo-a4a9a46a87221aaa40e145602a9211e5542753a0.zip
gfx: Rewrite display list construction to make stacking-contexts more
first-class. 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.
Diffstat (limited to 'components/layout/fragment.rs')
-rw-r--r--components/layout/fragment.rs26
1 files changed, 23 insertions, 3 deletions
diff --git a/components/layout/fragment.rs b/components/layout/fragment.rs
index d9fd9db4839..def9cd33776 100644
--- a/components/layout/fragment.rs
+++ b/components/layout/fragment.rs
@@ -1481,11 +1481,31 @@ impl Fragment {
self.style = (*new_style).clone()
}
- pub fn abs_bounds_from_origin(&self, fragment_origin: &Point2D<Au>) -> Rect<Au> {
+ /// Given the stacking-context-relative position of the containing flow, returns the boundaries
+ /// of this fragment relative to the parent stacking context.
+ pub fn stacking_relative_bounds(&self, stacking_relative_flow_origin: &Point2D<Au>)
+ -> Rect<Au> {
// FIXME(#2795): Get the real container size
let container_size = Size2D::zero();
- self.border_box.to_physical(self.style.writing_mode, container_size)
- .translate(fragment_origin)
+ self.border_box
+ .to_physical(self.style.writing_mode, container_size)
+ .translate(stacking_relative_flow_origin)
+ }
+
+ /// Returns true if this fragment establishes a new stacking context and false otherwise.
+ pub fn establishes_stacking_context(&self) -> bool {
+ match self.style().get_box().position {
+ position::absolute | position::fixed => {
+ // FIXME(pcwalton): This should only establish a new stacking context when
+ // `z-index` is not `auto`. But this matches what we did before.
+ true
+ }
+ position::relative | position::static_ => {
+ // FIXME(pcwalton): `position: relative` establishes a new stacking context if
+ // `z-index` is not `auto`. But this matches what we did before.
+ false
+ }
+ }
}
}