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 upImplement some missing convenience traits. #200
Conversation
|
r? @kvark |
| @@ -633,6 +633,23 @@ where T: Copy + fmt::Debug + | |||
| } | |||
| } | |||
|
|
|||
| impl<T: Copy, Src, Dst> Into<[T; 16]> for TypedTransform3D<T, Src, Dst> { | |||
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
nical
May 29, 2017
Author
Collaborator
2D transforms don't need to implement perspective or other weird operations, so you only need the 2x2 matrix which can encode the scale and rotation, plus the two components that have the transform this gives you a 3x3 matrix where all of the missing components are zero.
3D transforms have a richer set of operation that require all of the components of the 4x4 matrix.
This comment has been minimized.
This comment has been minimized.
kvark
May 29, 2017
Member
don't you see it somewhat inconsistent? it's almost asking for AffineTransform3D being different from just Transform3D.
This comment has been minimized.
This comment has been minimized.
nical
May 30, 2017
•
Author
Collaborator
In practice, most 2d rendering libraries (cairo, skia, moz2d, etc.) store 2d transforms the way we do, so using arrays of 6 elements is what's most consistent in a useful way.
If we added the implicit components we could serialize but not deserialize since we would not know what to do with the extra values if they are not zero.
|
Another concern is the choice of |
That comes down to personal taste, I have a tendency to favor flat arrays because it subjectively feels simpler, but I an see why some may want to structure that into row arrays. I don't see a reason to not do both, so I added |
nical
changed the title
| @@ -54,6 +55,14 @@ impl<T: Serialize, U> Serialize for TypedRect<T, U> { | |||
| } | |||
| } | |||
|
|
|||
| impl<T: Hash, U> Hash for TypedRect<T, U> | |||
| { | |||
This comment has been minimized.
This comment has been minimized.
To be honest, I was thinking that since it's not obvious, we should rather not provide any conversions. |
|
@bors-servo r+ |
|
|
Implement some missing convenience traits. Implement `From<[T; N]>` and `Into<[T; N]>` for points and vectors, Implement Hash for rects, and add some helper methods to convert transforms from and to arrays. <!-- 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/200) <!-- Reviewable:end -->
|
|
|
@bors-servo retry |
1 similar comment
|
@bors-servo retry |
Implement some missing convenience traits. Implement `From<[T; N]>` and `Into<[T; N]>` for points and vectors, Implement Hash for rects, and add some helper methods to convert transforms from and to arrays. <!-- 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/200) <!-- Reviewable:end -->
|
|
nical commentedMay 29, 2017
•
edited
Implement
From<[T; N]>andInto<[T; N]>for points and vectors, Implement Hash for rects, and add some helper methods to convert transforms from and to arrays.This change is