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<linuxhi...@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
