[OpenJDK 2D-Dev] [9] Review Request: 8167310 The graphics clip is incorrectly rounded for some fractional scales

Sergey Bylokhov Sergey.Bylokhov at oracle.com
Sat Oct 8 21:15:47 UTC 2016


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.



More information about the 2d-dev mailing list