That looks good. +1
...jim
On 10/11/16 4:32 PM, Sergey Bylokhov wrote:
On 11.10.16 23:12, Jim Graham wrote:
Also, is it worth having a protective test for Rectangle in the
intersect(Rectangle2D) method to avoid all of the double math when the
rectangle was already an
On 11.10.16 23:12, Jim Graham wrote:
Also, is it worth having a protective test for Rectangle in the
intersect(Rectangle2D) method to avoid all of the double math when the
rectangle was already an integer one?
Yes, this code can be moved from SunGraphics2D:
Also, is it worth having a protective test for Rectangle in the intersect(Rectangle2D) method to avoid all of the double
math when the rectangle was already an integer one?
...jim
On 10/10/16 4:37 PM, Sergey Bylokhov wrote:
On 10.10.16 23:42, Jim Graham wrote:
Can we
One last thing. In the clipRound() method you mention that NaN evaluates to 0. I assume that is just an observation
that we'd end up in the "(int) ceil()" case and the cast returns a 0.
In the case of a path we omit NaN coordinates, which means skipping segments in a path until they become
On 10/11/16 12: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
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 so the fuzzy pixels along the boundary of an
On 10/10/16 3:23 PM, Phil Race wrote:
That last sentence sounds like the right answer in principle but I don't know
if we'll be unpleasantly surprised
by some consequence of "... that setClip(Shape) and fill(Shape) might disagree
.."
-phil.
As I was thinking more about this last night we
On 10/10/16 3:53 PM, Sergey Bylokhov wrote:
On 11.10.16 1:23, Phil Race wrote:
Yes, I think adjacent drawImage requests should not overlap. We
should look into this separately.
So previously, overlapping of the clip bounds ensured adjacent images
were not drawn
over-lapped .. but with this
