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 int/longs. This is an unnecessary for double type, the code is removed and a spec of the method is also updated.
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 can illustrate this with the following:
Yes, it was in the lines. In the new version I changed the line width to 6. This value will fill the whole clip in all tested scales[0.1 - 4]. I did not use two lines because I use "srcover+transparentColor" and two lines can produce one more color after overlapping.
Note that this will cover some pixels to the left of the clip (which should be clipped out), but it will leave a gap between the right side of the line and the right side of the clip, i.e. the next step (of about 0.75 pixels - which are likely to include a pixel center and thus leave a white pixel). At higher scales, the gap will be higher and more likely to include white pixels. A line width of 2 (actually 2*stepsize where stepsize=1 here) means that the line will cover an entire step regardless of the scale. Hopefully that will remove the need for the WHITE test in the validate method. Note that STROKE_CONTROL may come into play here as well. The above analysis is for STROKE_PURE semantics, but the normalization/biasing of STROKE_NORMALIZE might increase or decrease the chance that the above will fix the issue and may require an even larger line width. Another option without setting line width would be to draw two lines, one at step and another at step+1, which would test for gaps between adjacent lines as well as ensure that the test covers the "right half" of the line at step and the "left half" of the line at step+1... ...jim On 10/7/16 6:18 AM, Sergey Bylokhov wrote: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 details: http://mail.openjdk.java.net/pipermail/2d-dev/2016-July/007299.html So getBounds() produces the bigger Rectangle than is necessary and our clip became bigger as well. This means that in some fractional scales such clips are overlapping. The test will test fillRect, DrawImage, DrawLine methods and validates that there are no any overlapping if we set the clip.(The gaps between touched pixels are allowed only for lines). Note that as I understand the code this fix should affect the DrawLines, because in some situations it is possible that two lines are overlapped without clip. And two other cases(fillRect, drawImage) should work without clip, but only fillRect works. It is discussed here: http://mail.openjdk.java.net/pipermail/2d-dev/2016-October/007766.html Bug: https://bugs.openjdk.java.net/browse/JDK-8167310 Webrev can be found at: http://cr.openjdk.java.net/~serb/8167310/webrev.00
-- Best regards, Sergey.
