The
AffineTransform
class represents a 2D affine transform
that performs a linear mapping from 2D coordinates to other 2D
coordinates that preserves the "straightness" and
"parallelness" of lines. Affine transformations can be constructed
using sequences of translations, scales, flips, rotations, and shears.
Such a coordinate transformation can be represented by a 3 row by
3 column matrix with an implied last row of [ 0 0 1 ]. This matrix
transforms source coordinates (x,y)
into
destination coordinates (x',y')
by considering
them to be a column vector and multiplying the coordinate vector
by the matrix according to the following process:
[ x'] [ m00 m01 m02 ] [ x ] [ m00x + m01y + m02 ]
[ y'] = [ m10 m11 m12 ] [ y ] = [ m10x + m11y + m12 ]
[ 1 ] [ 0 0 1 ] [ 1 ] [ 1 ]
Handling 90-Degree Rotations
In some variations of the rotate
methods in the
AffineTransform
class, a double-precision argument
specifies the angle of rotation in radians.
These methods have special handling for rotations of approximately
90 degrees (including multiples such as 180, 270, and 360 degrees),
so that the common case of quadrant rotation is handled more
efficiently.
This special handling can cause angles very close to multiples of
90 degrees to be treated as if they were exact multiples of
90 degrees.
For small multiples of 90 degrees the range of angles treated
as a quadrant rotation is approximately 0.00000121 degrees wide.
This section explains why such special care is needed and how
it is implemented.
Since 90 degrees is represented as PI/2
in radians,
and since PI is a transcendental (and therefore irrational) number,
it is not possible to exactly represent a multiple of 90 degrees as
an exact double precision value measured in radians.
As a result it is theoretically impossible to describe quadrant
rotations (90, 180, 270 or 360 degrees) using these values.
Double precision floating point values can get very close to
non-zero multiples of PI/2
but never close enough
for the sine or cosine to be exactly 0.0, 1.0 or -1.0.
The implementations of Math.sin()
and
Math.cos()
correspondingly never return 0.0
for any case other than Math.sin(0.0)
.
These same implementations do, however, return exactly 1.0 and
-1.0 for some range of numbers around each multiple of 90
degrees since the correct answer is so close to 1.0 or -1.0 that
the double precision significand cannot represent the difference
as accurately as it can for numbers that are near 0.0.
The net result of these issues is that if the
Math.sin()
and Math.cos()
methods
are used to directly generate the values for the matrix modifications
during these radian-based rotation operations then the resulting
transform is never strictly classifiable as a quadrant rotation
even for a simple case like rotate(Math.PI/2.0)
,
due to minor variations in the matrix caused by the non-0.0 values
obtained for the sine and cosine.
If these transforms are not classified as quadrant rotations then
subsequent code which attempts to optimize further operations based
upon the type of the transform will be relegated to its most general
implementation.
Because quadrant rotations are fairly common,
this class should handle these cases reasonably quickly, both in
applying the rotations to the transform and in applying the resulting
transform to the coordinates.
To facilitate this optimal handling, the methods which take an angle
of rotation measured in radians attempt to detect angles that are
intended to be quadrant rotations and treat them as such.
These methods therefore treat an angle theta as a quadrant
rotation if either Math.sin(theta)
or
Math.cos(theta)
returns exactly 1.0 or -1.0.
As a rule of thumb, this property holds true for a range of
approximately 0.0000000211 radians (or 0.00000121 degrees) around
small multiples of Math.PI/2.0
.