Hi Alexandr,
That code is coming up with maximum extents for the operation, not the exact edges that will be rendered. It passes
them down to the native TransformHelper method which refines them using the exact calculations it will use to render the
pixels.
Admittedly, the calculations you
I suppose that there could be a 4th bug about the fact that the trimming/refining code in the native TransformHelper is
based on an inverse transform and subject to bit error, but it's not easy to figure out how to refine it further. Note
that it could also cause us to omit a row of pixels in
350 if (!isAccelerationEnabled()) {
351 // Ideally there is no need to re-create a software
surface. But
352 // some OSs allow changes to display state at runtime.
Such a
353 // provision would cause mismatch in graphics
configuration of the
354
