Tweaking might reduce the number of cases where the reverse transform
makes a different edge condition decision than the forward transform,
but it will never completely eliminate it and so the refine code (which
exists because forward computations don't always match reverse
computations) would
But probably it is possible to tweak the transform? I mean that we can
apply the "round", then calculate the diff between resulted destination
and destination based on transform, and shift/rescale the transform so
it will map exactly the pixels from source edges to destination edges.
On
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
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
On 10/11/16 12:49 PM, Jim Graham wrote:
Right now I tried to fix overlapping, which produce visible artifacts and were
considered as a bugs. The next issue
which I would like to fix is a overlapping of drawImage().
Yes, that bears investigation...
I looked into it and the issue is basically
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
On 10.10.16 23:42, Jim Graham wrote:
Can we also not use MAX_INT for the drawImage test case? Either have
the drawImage follow the clip around or choose an appropriate non-limit
size to cover the worst case scale with some margin for error...
Something like this?
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 fix they might be ?
The fix change only
On 10/10/2016 01:34 PM, Jim Graham wrote:
[CC'ing Phil in case he has some suggestions for how the API should
work...]
Responding just to additional questions in this email...
On 10/10/16 12:45 PM, Sergey Bylokhov wrote:
The additional questions:
- In the current fix we change behavior of
Can we also not use MAX_INT for the drawImage test case? Either have the drawImage follow the clip around or choose an
appropriate non-limit size to cover the worst case scale with some margin for error...
...jim
On 10/10/16 12:45 PM, Sergey Bylokhov wrote:
An updated
[CC'ing Phil in case he has some suggestions for how the API should work...]
Responding just to additional questions in this email...
On 10/10/16 12:45 PM, Sergey Bylokhov wrote:
The additional questions:
- In the current fix we change behavior of the clip. Before the fix if we set
the clip
An updated version:
http://cr.openjdk.java.net/~serb/8167310/webrev.03
- STROKE_PURE is used in the test, the line width is set to 2.01. This
also fixed the difference between clips(Shape vs Rectangle).
- The if statement is changed as suggested.
The additional questions:
- In the current
Yes, we do bias both. So, the code we just added doesn't match the biasing that is performed by the fill operations, we
should probably make it be the same. You can see that it computes a bias boolean when it calls getFillSSI(), but the
bias is applied natively in the native ShapeSpanIterator
That does sound like a problem. Does it do the same thing with new Path2D(Rectangle)? The Area class does some
processing on the path and it would be nice to eliminate that as a potential source of this problem. I don't have a
buildable JDK9 repo right now that I can fire off some quick tests
On 10.10.16 22:04, Sergey Bylokhov wrote:
On 10.10.16 21:55, Sergey Bylokhov wrote:
Will give us a pass on the test as long as we made the same mistake for
both the rect clip and the shape clip. I think you want "(rgb !=
goldRGB) || (rgb != GREEN && rgb != RED)"...?
Correct, I will update
On 10/10/16 11:55 AM, Sergey Bylokhov wrote:
On 10.10.16 21:31, Jim Graham wrote:
OK, but you only need a line width of 2.0 to cover the gap regardless of
scale. Line width scales in user space so larger scales scale up the
line width along with the clip region being rendered. With
On 10.10.16 21:55, Sergey Bylokhov wrote:
Will give us a pass on the test as long as we made the same mistake for
both the rect clip and the shape clip. I think you want "(rgb !=
goldRGB) || (rgb != GREEN && rgb != RED)"...?
Correct, I will update the test.
surprisingly but it is produce
On 10.10.16 21:31, Jim Graham wrote:
OK, but you only need a line width of 2.0 to cover the gap regardless of
scale. Line width scales in user space so larger scales scale up the
line width along with the clip region being rendered. With
STROKE_CONTROL on, 2.0 is plenty because the line is
Hi Sergey,
Comments inline...
On 10/8/16 2:15 PM, Sergey Bylokhov wrote:
On 08.10.16 0:58, Jim Graham wrote:
That looks great. A couple of questions.
An updated version and a comments inline:
http://cr.openjdk.java.net/~serb/8167310/webrev.01
Test case:
Where do you get white gaps? Is
On 08.10.16 0:58, Jim Graham wrote:
That looks great. A couple of questions.
An updated version and a comments inline:
http://cr.openjdk.java.net/~serb/8167310/webrev.01
Region, line 132: why are you testing for newv > coordinate?
That was an attempt to catch an overflow like in case of
That looks great. A couple of questions.
Region, line 132: why are you testing for newv > coordinate?
Test case:
Where do you get white gaps? Is it in the line test? If so, then consider setting the line width higher (or drawing 2
lines per iteration as I mention in the last paragraph). I
Hello.
Please review the fix for jdk9.
This is bug which was found when the fractional scale is used in Swing.
The problem is that if we save a usrClip as Rectangle2D then we
incorrectly intersect it with device clip. The problem is in the
RectangularShape.getBounds() method, see more
29 matches
Mail list logo
