Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upMix stacking contexts into the positioned content list #8266
Conversation
|
@pcwalton r? This is the main prerequisite for eliminating |
88b6ca2
to
5c63287
5c63287
to
90a16a4
| @@ -206,23 +204,31 @@ impl DisplayList { | |||
| /// inefficient and should only be used for debugging. | |||
| pub fn all_display_items(&self) -> Vec<DisplayItem> { | |||
| let mut result = Vec::new(); | |||
| fn add_all_display_items_for_item(result: &mut Vec<DisplayItem>, item: &DisplayItem) { | |||
This comment has been minimized.
This comment has been minimized.
pcwalton
Nov 2, 2015
Contributor
Maybe just call this flatten? That's the terminology WR uses for a similar operation.
|
|
||
| fn has_negative_z_index(&self) -> bool { | ||
| if let &DisplayItem::StackingContextClass(ref stacking_context) = self { | ||
| return stacking_context.z_index < 0 |
This comment has been minimized.
This comment has been minimized.
| match paint_context.transient_clip { | ||
| Some(ref transient_clip) if transient_clip == this_clip => {} | ||
| Some(_) | None => paint_context.push_transient_clip((*this_clip).clone()), | ||
| fn draw_into_context(&self, transform: &Matrix4, paint_context: &mut PaintContext) { |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
mrobinson
Nov 2, 2015
Author
Member
Sure. transform is necessary to properly draw StackingContexts, because it is used to calculate a new transform based on the StackingContexts bounds (display items are positioned relative to stacking contexts). Before StackingContexts were drawn outside of DisplayItem::draw_into_context (in DisplayList::draw_into_context). Now that StackingContexts can be DisplayItems it is moved here and the transform must be included in the case that this item is a StackingContext item.
90a16a4
to
a2acb2a
|
@pcwalton Thanks, as always, for the review comments. I think I've made all the changes you suggested in the latest version of the branch. Do you see any other issues here? |
Adding overflow:hidden to an absolute positioned div will change it's stacking order. referencing servo#8122
|
Not sure if you want to address this issue in this PR or not, but for the record: #8310 |
a2acb2a
to
5b3e953
|
@paulrouget Thanks for finding that issue! I've fixed it in the latest version. I had omitted some code that was removed. |
|
@bors-servo: r+ |
|
|
|
@bors-servo: r- @mrobinson wants to add a test |
|
@bors-servo: r+ |
|
|
Mix stacking contexts into the positioned content list Sometimes positioned content needs to be layered on top of stacking contexts. The layer synthesis code can do this, but the current design prevents it because stacking contexts are stored in a separate struct member. In order to preserve tree order, mix stacking contexts into the positioned content list, by adding a new StackingContextClass DisplayItem. Such items do not have a base DisplayItem. In some ways this simplifies the code, because we no longer have to have a separate code path in the StackingContextLayerCreator. <!-- Reviewable:start --> [<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/8266) <!-- Reviewable:end -->
|
|
|
Looks like some tests are now passing with this change. I'll update the branch and reupload. |
Sometimes positioned content needs to be layered on top of stacking contexts. The layer synthesis code can do this, but the current design prevents it because stacking contexts are stored in a separate struct member. In order to preserve tree order, mix stacking contexts into the positioned content list, by adding a new StackingContextClass DisplayItem. Such items do not have a base DisplayItem. In some ways this simplifies the code, because we no longer have to have a separate code path in the StackingContextLayerCreator. Fixes #7779. Fixes #7983. Fixes #8122. Fixes #8310.
5b3e953
to
c1a38e2
|
@bors-servo: r=pcwalton I confirmed with @pcwalton via IRC that he was okay with trying to land this again. |
|
|
Mix stacking contexts into the positioned content list Sometimes positioned content needs to be layered on top of stacking contexts. The layer synthesis code can do this, but the current design prevents it because stacking contexts are stored in a separate struct member. In order to preserve tree order, mix stacking contexts into the positioned content list, by adding a new StackingContextClass DisplayItem. Such items do not have a base DisplayItem. In some ways this simplifies the code, because we no longer have to have a separate code path in the StackingContextLayerCreator. <!-- Reviewable:start --> [<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/8266) <!-- Reviewable:end -->
|
|
mrobinson commentedOct 30, 2015
Sometimes positioned content needs to be layered on top of stacking
contexts. The layer synthesis code can do this, but the current design
prevents it because stacking contexts are stored in a separate struct
member. In order to preserve tree order, mix stacking contexts into the
positioned content list, by adding a new StackingContextClass
DisplayItem. Such items do not have a base DisplayItem.
In some ways this simplifies the code, because we no longer have to
have a separate code path in the StackingContextLayerCreator.