Affine transforms - matrix algebra
martin.desruisseaux at geomatys.fr
Mon Jul 23 03:09:47 PDT 2012
Le 23/07/12 11:11, Pavel Safrata a écrit :
> We need to add manual transformation methods to Transfrom class. This
> is very important, I can't believe I've forgotten them..
I noticed that those methods were missing, but I though that it was on
> public Point3D transform(Point3D point)
> public Bounds transform(Bounds bounds)
> Any other?
I think that the following one is very important for performance reasons:
void transform(double srcPts, int srcOffset, double dstPts, int
dstOffset, int numPts);
with semantic identical to the one currently in the Java2D
AffineTransform. The other variants working on float arrays and the ones
mixing float/double arrays would also be useful. Alternatively, methods
working on java.nio.Float/DoubleBuffer instead than arrays would also be
okay if performances are the same (this would avoid the need for
src/dstOffset and numPts arguments).
Maybe it would be worth to phrase the javadoc in a way that leave room
for slight implementation-dependant differences in the numerical
results. For example the javadoc of Math.sin said "The computed result
must be within 1 ulp of the exact result". I think that something
similar for the transform methods (the number of ulp is yet to be
determined) would be useful in order to leaves room for
hardward-accelerated implementations. I'm thinking especially about the
"fused add-multiply" operation found on many modern processor, which
doesn't produce exactly the same result than multiplication followed by
addition in Java. It would be nice if Transform implementations were
allowed to use such operations on platforms that support it, despite the
slight difference in numerical results.
> Rename the MatrixArrayType constants to MAT_2D_3x2, MAT_2D_3x3,
> MAT_3D_3x4, MAT_3D_4x4, do you agree?
I don't really have better idea at this time... I wonder if we could
find a way to merge with the VAT_* constants...
More information about the openjfx-dev