Recently a fix was integrated for bug 4916948 which causes the
image rendering pipeline to invoke the image transformation code
when there is a chance that the sub-pixel positioning of the pixels
might make them subject to interpolation or to slight changes in
the sampling of the sources pixels.

Unfortunately the new decisions are incredibly strict and basically
reject any transform that does not map an image to exact pixel
boundaries with no leeway for any sub-pixel positioning. This very
strict cutoff is not realistic for a couple of reasons:

- Often transforms are the result of a number of
smaller operations which result in scale or
translation components that are very slightly
off from exact integer numbers even though
the intent is to end on a whole number.

- Even if the transform numbers are off by a tiny
amount, these very tiny sub-pixel variations
may not result in changes to either the pixel
sampling of the original image or in the
blending of adjacent pixel values for interpolated
image transforms since most image operations are
performed in a discrete 8-bit per color component
mathematical space. If the sub-pixel positioning
is not off by more than 1 out of an 8-bit number
then the results of the interpolation calculation
will be identical anyway.

The test case for bug 4989837 demonstrates one problem that can
arise when what should be a simple copy operation is instead
implemented using a full image transformation operation. A
more widely observable result will be the poorer performance
of many operations that used to map to a simple image copy but
which now go through the much slower image transformation,
even if the quality problems seen in 4989837 are not visible
to the user in those cases. Such performance losses could
be a serious regression for users who require fast image
operations.