Add f64 version of transform.to_transform_3d_matrix

[saschanaz]

DOMMatrix on Firefox 69 now uses double, but when parsing CSS through new DOMMatrix("matrix(...)") it depends on transform.to_transform_3d_matrix() and then loses precision. (And thus failing relevant WPT tests.)

https://github.com/mozilla/gecko-dev/blob/da14c413ef663eb1ba246799e94a240f81c42488/dom/base/DOMMatrix.cpp#L778

https://github.com/mozilla/gecko-dev/blob/a7a4c4c9df4b7b96c8d35b9f642c8b00a041092f/layout/style/ServoCSSParser.cpp#L55

https://github.com/mozilla/gecko-dev/blob/ea4843bd849cef3ecf281f8826626eea42550bda/servo/ports/geckolib/glue.rs#L6329

servo/components/style/values/generics/transform.rs

Lines 525 to 561 in b4fb2cd

	impl<T: ToMatrix> Transform<T> {
	/// Return the equivalent 3d matrix of this transform list.
	/// We return a pair: the first one is the transform matrix, and the second one
	/// indicates if there is any 3d transform function in this transform list.
	#[cfg_attr(rustfmt, rustfmt_skip)]
	pub fn to_transform_3d_matrix(
	&self,
	reference_box: Option<&Rect<Au>>
	) -> Result<(Transform3D<CSSFloat>, bool), ()> {
	let cast_3d_transform = |m: Transform3D<f64>| -> Transform3D<CSSFloat> {
	use std::{f32, f64};
	let cast = |v: f64| { v.min(f32::MAX as f64).max(f32::MIN as f64) as f32 };
	Transform3D::row_major(
	cast(m.m11), cast(m.m12), cast(m.m13), cast(m.m14),
	cast(m.m21), cast(m.m22), cast(m.m23), cast(m.m24),
	cast(m.m31), cast(m.m32), cast(m.m33), cast(m.m34),
	cast(m.m41), cast(m.m42), cast(m.m43), cast(m.m44),
	)
	};
	// We intentionally use Transform3D<f64> during computation to avoid error propagation
	// because using f32 to compute triangle functions (e.g. in create_rotation()) is not
	// accurate enough. In Gecko, we also use "double" to compute the triangle functions.
	// Therefore, let's use Transform3D<f64> during matrix computation and cast it into f32
	// in the end.
	let mut transform = Transform3D::<f64>::identity();
	let mut contain_3d = false;
	for operation in &*self.0 {
	let matrix = operation.to_3d_matrix(reference_box)?;
	contain_3d |= operation.is_3d();
	transform = transform.pre_mul(&matrix);
	}
	Ok((cast_3d_transform(transform), contain_3d))
	}
	}

Could we add a f64 version of the API so that we won't lose precision?

Example:

new DOMMatrix("matrix(0.3333333333333333, 0, 0, 0, 0, 0)").m11
// expected: 0.3333333333333333
// actual: 0.3333333432674408

Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1560705

[jdm]

@emilio Any opinion on this question?

[highfive]

cc @emilio

[emilio]

@saschanaz fwiw you can edit that code directly in Firefox, I'd file a bug in the "CSS Parsing and Computation" component. I'm happy to help out or write the patch.

[emilio]

That being said we parse matrix as a matrix of CSSFloats which is a f32 under the hood, so I'm not sure how fixing just that function would help.

[saschanaz]

we parse matrix as a matrix of CSSFloats which is a f32 under the hood

In that case the parser should support f64 first... So this Number should be modified to use f64, right?

servo/components/style/values/specified/mod.rs

Lines 158 to 168 in b4fb2cd

	/// A CSS `<number>` specified value.
	///
	/// https://drafts.csswg.org/css-values-3/#number-value
	#[derive(Clone, Copy, Debug, MallocSizeOf, PartialEq, PartialOrd, ToShmem)]
	pub struct Number {
	/// The numeric value itself.
	value: CSSFloat,
	/// If this number came from a calc() expression, this tells how clamping
	/// should be done on the value.
	calc_clamping_mode: Option<AllowedNumericType>,
	}

Looks like it will cause a large downstream changes.

[emilio]

Presumably, and yes, not only that but also will double memory usage in most places. We store a lot of these...