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?
http://cr.openjdk.java.net/~se
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 behav
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 t
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 fi
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 c
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 the
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
STROKE_CO
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 the
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 norm
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 i
13 matches
Mail list logo
