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 so
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 p
On 10/11/2016 10:13 PM, Sergey Bylokhov wrote:
On 11.10.16 21:54, Jim Graham wrote:
Additionally, for AA rendering, there is no such thing as
"setClip(someShape)" and "fill(sameShape)" being identical no matter how
much we predict which rules they may want because clips are inherently
non-AA and
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
