Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify the difference between packed layers and stacking contexts #824

Merged
merged 1 commit into from Feb 3, 2017

Conversation

@mrobinson
Copy link
Member

mrobinson commented Feb 2, 2017

Eventually scroll layers will create packed layers as well, so this will
help to keep things clear. This shouldn't change behavior, because
currently packed layer ids will always be equal to the stacking context
ids of their owners.


This change is Reviewable

@mrobinson
Copy link
Member Author

mrobinson commented Feb 2, 2017

@glennw r?

@bors-servo
Copy link
Contributor

bors-servo commented Feb 2, 2017

The latest upstream changes (presumably #802) made this pull request unmergeable. Please resolve the merge conflicts.

@kvark
Copy link
Member

kvark commented Feb 2, 2017

currently packed layer ids will always be equal to the stacking context
ids of their owners

Let's hope all of the are called sc_index so that we don't miss any ;)

@kvark
kvark approved these changes Feb 2, 2017
Copy link
Member

kvark left a comment

Looks pretty straightforward and clean in terms of implementation.
For the future, I'd like to remove those xf_rect.as_ref().unwrap() calls and revise the coordinate system names.

&[]);
context.builder.push_stacking_context(layer_rect,
&ClipRegion::simple(&layer_rect),
LayerToScrollTransform::identity(),

This comment has been minimized.

@kvark

kvark Feb 2, 2017

Member

Not directly related to this PR, but is it correct to still call it LayerToScrollTransform?
AFAIK, the SC's/items are attached to their reference frames, but the transformation we pass here is relative to the parent stacking context (not necessarily the scroll layer).

This comment has been minimized.

@mrobinson

mrobinson Feb 2, 2017

Author Member

@kvark, I think you are right. The naming of this is off now. There is a chance that in the future StackingContexts won't have transforms at all. It depends if we decide to make all coordinates relative to reference frames or not.

This comment has been minimized.

@kvark

kvark Feb 2, 2017

Member

Yep, I'd say let's not have the transformations in there. Since they only affect the initial placement of items, we should use it and forget about them, only keeping the reference frames in our sight.

@mrobinson mrobinson force-pushed the mrobinson:packed-layer-id branch from 8870224 to e115f89 Feb 2, 2017
@mrobinson
Copy link
Member Author

mrobinson commented Feb 2, 2017

@kvark, thanks for looking at this. I've pushed a new rebased version with a few other minor naming changes and a new use of Default::default().

@kvark
kvark approved these changes Feb 2, 2017
impl Default for PackedStackingContext {
fn default() -> PackedStackingContext {
PackedStackingContext {
impl Default for PackedLayer {

This comment has been minimized.

@kvark

kvark Feb 2, 2017

Member

I believe the semantics of Default is misused here. It's not a "default" layer, it's an empty one. Default is applicable where you could drop it if you don't care, and it's going to somewhat work. This is not the case here.

This comment has been minimized.

@mrobinson

mrobinson Feb 2, 2017

Author Member

Hrm. Okay. I'm happy to change it, but does that mean that the implementation of Default::default should change.

This comment has been minimized.

@kvark

kvark Feb 2, 2017

Member

Since there was already impl Default for PackedStackingContext, this is not something that has to be done in your PR. But for the future I think we should remove the impl Default and just have the same thing as an fn empty() -> PackedLayer constructor. No implementation change needed.

@glennw glennw closed this Feb 2, 2017
@glennw glennw reopened this Feb 2, 2017
@mrobinson
Copy link
Member Author

mrobinson commented Feb 3, 2017

The build failure seems to be

Could not open dynamic library `OsMesa`
@glennw
Copy link
Member

glennw commented Feb 3, 2017

I think the build failure should be resolved now (I reverted the commit that seems to cause that) - but travis might need a rebuild?

@mrobinson
Copy link
Member Author

mrobinson commented Feb 3, 2017

@bors-servo
Copy link
Contributor

bors-servo commented Feb 3, 2017

Trying commit e115f89 with merge 9df10a0...

bors-servo added a commit that referenced this pull request Feb 3, 2017
Clarify the difference between packed layers and stacking contexts

Eventually scroll layers will create packed layers as well, so this will
help to keep things clear. This shouldn't change behavior, because
currently packed layer ids will always be equal to the stacking context
ids of their owners.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/webrender/824)
<!-- Reviewable:end -->
@bors-servo
Copy link
Contributor

bors-servo commented Feb 3, 2017

☀️ Test successful - status-travis
State: approved= try=True

Eventually scroll layers will create packed layers as well, so this will
help to keep things clear. This shouldn't change behavior, because
currently packed layer ids will always be equal to the stacking context
ids of their owners.
@mrobinson mrobinson force-pushed the mrobinson:packed-layer-id branch from e115f89 to fce5d7c Feb 3, 2017
@mrobinson
Copy link
Member Author

mrobinson commented Feb 3, 2017

This is related to #742, by the way.

@mrobinson
Copy link
Member Author

mrobinson commented Feb 3, 2017

@bors-servo r=kvark

@bors-servo
Copy link
Contributor

bors-servo commented Feb 3, 2017

📌 Commit fce5d7c has been approved by kvark

@bors-servo
Copy link
Contributor

bors-servo commented Feb 3, 2017

Testing commit fce5d7c with merge a63d0a2...

bors-servo added a commit that referenced this pull request Feb 3, 2017
Clarify the difference between packed layers and stacking contexts

Eventually scroll layers will create packed layers as well, so this will
help to keep things clear. This shouldn't change behavior, because
currently packed layer ids will always be equal to the stacking context
ids of their owners.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/webrender/824)
<!-- Reviewable:end -->
@bors-servo
Copy link
Contributor

bors-servo commented Feb 3, 2017

☀️ Test successful - status-travis
Approved by: kvark
Pushing a63d0a2 to master...

@bors-servo bors-servo merged commit fce5d7c into servo:master Feb 3, 2017
3 checks passed
3 checks passed
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details
@mrobinson mrobinson deleted the mrobinson:packed-layer-id branch Feb 3, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants
You can’t perform that action at this time.