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

Sync changes from mozilla-central gfx/wr #3851

Merged
merged 3 commits into from Feb 5, 2020
Merged
Changes from 1 commit
Commits
File filter...
Filter file types
Jump to…
Jump to file
Failed to load files.

Always

Just for now

Bug 1613375 - Always use reference frame origin offset in snapping tr…

…ansforms. r=nical

We incorporate the reference frame origin offset for non-animated
transforms, but forgot for animated transforms. Since the offset itself
is not animated, we should still incorporate it into the snapping
transform.

Differential Revision: https://phabricator.services.mozilla.com/D61689

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/a2ed78dab7bcf0cf5a0ff49606cafdd55b2f2fd9
  • Loading branch information
aosmond authored and moz-gfx committed Feb 5, 2020
commit 5d368c34ab35a06dcda60742d2749e5920efb78e
@@ -699,8 +699,12 @@ impl SpatialNode {
}

// Assume animations start at the identity transform for snapping purposes.
// We still want to incorporate the reference frame offset however.
// TODO(aosmond): Is there a better known starting point?
PropertyBinding::Binding(..) => ScaleOffset::identity(),
PropertyBinding::Binding(..) => {
let origin_offset = info.origin_in_parent_reference_frame;
ScaleOffset::from_offset(origin_offset.to_untyped())
}
}
}
_ => ScaleOffset::identity(),
ProTip! Use n and p to navigate between commits in a pull request.
You can’t perform that action at this time.