[OpenJDK 2D-Dev] Please review patch for 7150134

[Jim Graham]

Ah, so, in other words, the tests are just indicating that the line is 
bounded by the overall dimensions of the clip (for runaway size 
purposes), not that it is contained in the clip?

It might be nice to add a method to test just on the bounding box so 
that a complex clip wouldn't waste time to do a more thorough check of 
insideness, but complex clips should be rare enough and the contains 
check quick enough that it wouldn't matter much.  Or, you could just 
inline the bounding box tests using the hi/lo/x/y accessors:

	if (x1 >= r.getLoX() && x1 < r.getHiX() &&
             ...)

but again, not sure if it would arise frequently enough to be useful...

			...jim

On 4/5/2012 8:19 AM, Mario Torre wrote:
> Hi Clemens,
>
> The patch looks good to me.
>
> Just wondering what is the impact of those two checks:
>
> +        if (compClip.contains(transX1, transY1)
> +&&  compClip.contains(transX2, transY2)) {
>
> for the most common cases?
>
> Cheers,
> Mario
>
> 2012/4/5 Clemens Eisserer<linuxhippy at gmail.com>:
>> Hi,
>>
>> Please take a look at the patch for bug 7150134, located at
>> http://cr.openjdk.java.net/~ceisserer/7150134/
>>
>> The problem was caused by a fast-path in drawLine() which didn't take
>> clipping into account, therefor huge lines that would have been
>> clipped away caused OOMs in xrender's bresenham code. Because the
>> fast-path provides nice speedups (e.g. 300% for 20px horizontal lines
>> measured with J2DBench) I don't want to sacrifice it entirely.
>>
>> This fix only takes the fast-path in case the line is completly
>> un-clipped, otherwise it lets generic Java2D code handle it:
>> http://cr.openjdk.java.net/~ceisserer/7150134/
>>
>> Thanks, Clemens
>
>
>