-
Notifications
You must be signed in to change notification settings - Fork 107
Expose pre/post operations and transpositions explicitly, and add documentation. #149
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
Conversation
|
The PR is in a good state now (modulo making the git history pretty once eventual review comments have been addressed). Here is a summary of what's in there:
The above changes make it hard to fall into any trap by habit of using a convention or another.
And last but not least, I made a lot of code that was relying on Clone, rely on Copy instead. This simplifies things a great deal and I don't think anyone will ever use euclid with scalar types that are not Copy, although that's debatable. A lot of code was already only implemented for Copy types, especially in matrices, so I just generalized it to the rest of the library. |
|
I realize that's a lot for one PR, sorry. We can discuss, the different aspects of it here and I'll remove things if need be. |
src/matrix2d.rs
Outdated
| impl<T: Copy, Src, Dst> TypedMatrix2D<T, Src, Dst> { | ||
| pub fn to_array(&self) -> [T; 6] { | ||
| /// Create a matrix specifying its components in column-major order. | ||
| pub fn colum_major(m11: T, m21: T, m31: T, m12: T, m22: T, m32: T) -> TypedMatrix2D<T, Src, Dst> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
column
|
☔ The latest upstream changes (presumably #150) made this pull request unmergeable. Please resolve the merge conflicts. |
|
I'm curious why the change to make various types implement |
|
Never mind: somehow I thought you had made the matrix types implement Copy. I see now that it's just a constraint on the scalar type parameter. It's hard to imagine how that would be a problem. Comments from Reviewable |
|
Is there any reason not to also change the |
| #[inline] | ||
| pub fn from_lengths(x: Length<T, U>, y: Length<T, U>) -> TypedPoint2D<T, U> { | ||
| TypedPoint2D::new(x.get(), y.get()) | ||
| TypedPoint2D::new(x.0, y.0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
x.get() actually feels cleaner to me.
|
Since a lot of methods were already implemented on top of Copy scalar types, having the other half of the library implemented on top of (the less constrained) Clone trait was not particularly useful. Basing everything on top of Copy simplified the code quite a bit. No particular reason for Length's Clone constraint being left to Clone instead of Copy. For vector/matrix types the incentive was to make the methods easier to write and more readable while Length doesn't do anything fancy with its value. I can change it to use Copy as well If you prefer. |
|
It might be a bit neater though to have the same constraints everywhere. But it probably doesn't matter too much either way. |
|
☔ The latest upstream changes (presumably #153) made this pull request unmergeable. Please resolve the merge conflicts. |
|
I tried applying this to servo. The only thing missing is that |
|
When this is merged, I have made the relevant changes to Servo, which I'll make follow-on PRs for: |
src/matrix4d.rs
Outdated
| /// https://drafts.csswg.org/css-transforms/#funcdef-skew | ||
| /// | ||
| /// See https://drafts.csswg.org/css-transforms/#funcdef-skew | ||
| pub fn create_skew(alpha: T, beta: T) -> TypedMatrix4D<T, Src, Dst> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't alpha and beta be Radians<T> here?
|
Hi, I'm just back from holiday, I'll catch up with this asap, probably tomorrow, address comments, and rebase the PR. |
|
@nical No worries. I need to keep my unmerged DOMMatrix branch up to date, so I'm applying those changes anyway. |
|
I just rebased the branch, squashed it into a single commit fixed the skew parameters to use radians explicitly. I also rolled back the part where Point::zero() was renamed into Point::origin() which had landed in this branch accidentally. |
|
r? @pcwalton |
|
@bors-servo: r+ Very nice to see more work being done on euclid :) |
|
📌 Commit fe20f19 has been approved by |
|
⚡ Test exempted - status |
Expose pre/post operations and transpositions explicitly, and add documentation. This is a big PR, beware that it has a lot of breaking changes in the matrix types. It implements what I propose in issue #145 and issue #146, namely: * Remove mul for matrices in favor of explicit pre_mul and post_mul (similar to what we have in gecko). * Add Row-major and column-major serializers and constructors to matrices to help interfacing with dom matrices and external libs such as skia (the actual layout of the matrix types stays row-major but that's an implementation detail that only matters to the people looking at the memory in a debugger). * Add a whole bunch of methods that are used a lot in gecko. * Add a lot of documentation. This is still a work in progress but it's almost ready, so interested parties can start looking at it give feedback. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/euclid/149) <!-- Reviewable:end -->
This is a big PR, beware that it has a lot of breaking changes in the matrix types.
It implements what I propose in issue #145 and issue #146, namely:
This is still a work in progress but it's almost ready, so interested parties can start looking at it give feedback.
This change is