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

Allow gecko to provide the already-applied sticky offset to WR #1977

Merged
merged 1 commit into from Nov 6, 2017

Conversation

@staktrace
Copy link
Contributor

staktrace commented Nov 1, 2017

Fixes the remaining issue in #1912.

r? @mrobinson


This change is Reviewable

@staktrace staktrace force-pushed the staktrace:sticky branch 3 times, most recently from fc9752b to ffa56ab Nov 1, 2017
Copy link
Member

mrobinson left a comment

Sorry for taking so long to review this. I have a few comments...

@@ -454,6 +457,14 @@ impl ClipScrollNode {
}
}

fn clamp_to_bounds(

This comment has been minimized.

@mrobinson

mrobinson Nov 3, 2017

Member

It probably makes more sense for this to be a trait on f32 if possible. The self value is unused here.

}
debug_assert!(sticky_offset.y >= 0.0);
debug_assert!(sticky_offset.y + info.applied_offset.y >= 0.0);
}

if sticky_offset.y == 0.0 {

This comment has been minimized.

@mrobinson

mrobinson Nov 3, 2017

Member

Hrm. We don't need to test sticky_offset.y plus the applied offset?

This comment has been minimized.

@staktrace

staktrace Nov 3, 2017

Author Contributor

You're right, we do. When I thought it through before I thought this was correct but thinking it through again now you're right. (For posterity, the specific thought-example is the case where gecko paints something with a top-offset already applied, and then with the async scroll we completely unapply that offset and apply a bottom-offset).

@@ -999,6 +999,9 @@ impl YamlFrameWriter {

yaml_node(&mut v, "horizontal-offset-bounds", Yaml::Array(horizontal));
yaml_node(&mut v, "vertical-offset-bounds", Yaml::Array(vertical));

f32_node(&mut v, "applied-offset-x", item.applied_offset.x);

This comment has been minimized.

@mrobinson

mrobinson Nov 3, 2017

Member

Thanks for adding wrench support! I think it would be good to add a test for this as well, since there is a risk of breaking such a particular use case.

This comment has been minimized.

@staktrace

staktrace Nov 3, 2017

Author Contributor

I'm not entirely sure how to do this but I'll ask around.

// the calling code, stored in info.applied_offset, and the extra amount we
// computed as a result of scrolling, stored in sticky_offset) needs to be
// clamped to the provided bounds.
sticky_offset.y = self.clamp_to_bounds(sticky_offset.y + info.applied_offset.y, &info.vertical_offset_bounds) - info.applied_offset.y;

This comment has been minimized.

@mrobinson

mrobinson Nov 3, 2017

Member

These lines extend beyond 100 characters.

/// has been scrolled down, such that the sticky item's position needed to be offset
/// downwards by `applied_offset.y`. A negative y component corresponds to the upward
/// offset applied due to bottom-stickiness. The x-axis works analogously.
pub applied_offset: LayoutVector2D,

This comment has been minimized.

@mrobinson

mrobinson Nov 3, 2017

Member

Maybe this should be called something like previously_applied_offset to avoid confusing it with the current offset provided by WebRender?

This comment has been minimized.

@staktrace

staktrace Nov 3, 2017

Author Contributor

I was thinking of that too but wasn't sure how about variable name length. I can change it.

@staktrace staktrace force-pushed the staktrace:sticky branch from ffa56ab to 5ae5587 Nov 3, 2017
@staktrace
Copy link
Contributor Author

staktrace commented Nov 3, 2017

Updated. For the clamp function I just made a little lambda inside the main function which I think is cleaner than before. While writing the reftests I also discovered that neither sticky_offset.y == 0 nor sticky_offset.y + info.applied_offset.y == 0 were correct, so I fixed that up better and added a comment to indicate what happened there. Hopefully this version addresses all of your comments - let me know if there's anything else you'd like to see changed!

@staktrace
Copy link
Contributor Author

staktrace commented Nov 4, 2017

Travis failures are just timeouts; please ask bors to retry if the updated patch looks good to you.

@bors-servo
Copy link
Contributor

bors-servo commented Nov 5, 2017

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

Copy link
Member

mrobinson left a comment

Looks good to me. Feel free to rebase and land this.

@staktrace staktrace force-pushed the staktrace:sticky branch from 5ae5587 to 89af6d3 Nov 6, 2017
@staktrace
Copy link
Contributor Author

staktrace commented Nov 6, 2017

Rebased ^. Can somebody with permissions stamp this with r=mrobinson please? Thanks!

@glennw
Copy link
Member

glennw commented Nov 6, 2017

@bors-servo r=mrobinson

Thanks!

@bors-servo
Copy link
Contributor

bors-servo commented Nov 6, 2017

📌 Commit 89af6d3 has been approved by mrobinson

@bors-servo
Copy link
Contributor

bors-servo commented Nov 6, 2017

Testing commit 89af6d3 with merge ec47222...

bors-servo added a commit that referenced this pull request Nov 6, 2017
Allow gecko to provide the already-applied sticky offset to WR

Fixes the remaining issue in #1912.

r? @mrobinson

<!-- 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/1977)
<!-- Reviewable:end -->
@bors-servo
Copy link
Contributor

bors-servo commented Nov 6, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: mrobinson
Pushing ec47222 to master...

@bors-servo bors-servo merged commit 89af6d3 into servo:master Nov 6, 2017
4 checks passed
4 checks passed
Taskcluster (pull_request) TaskGroup: success
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details
@staktrace staktrace deleted the staktrace:sticky branch Nov 6, 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.