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
Hi Jim,
For a complex clip it is not enough to test the two endpoints so I don't
think this fix will work for a line that spans between two portions of a
non-rectangular clip over a region that is outside the clip...
This case is handled by the native clip, so it would just be a missed
I don't understand. You are checking to see if the line is inside the
clip, but your test will think that something is inside the clip when it
is not so the fast path code will be used for lines outside the clip.
If the case can handle lines outside the clip then why test at all?
Hi Jim,
I don't understand. You are checking to see if the line is inside the clip,
but your test will think that something is inside the clip when it is not so
the fast path code will be used for lines outside the clip. If the case
can handle lines outside the clip then why test at all?
For a complex clip it is not enough to test the two endpoints so I don't
think this fix will work for a line that spans between two portions of a
non-rectangular clip over a region that is outside the clip...
...jim
On 4/5/2012 5:49 AM, Clemens Eisserer wrote:
Hi,
Hi Phil,
Looks fine should solve the problem.
Thanks. Could you please push the patch?
Perhaps it would have been nice to
calculate the interpolation with the clip but then you'd need to pay
attention to whether it was a complex clip or a simple rectangular one
and it may be better to do
I'll push it on Monday .. or as soon as I can ..
I remember now, yes diagonal lines were not so hot anyway ..
BTW I saw an picked up that bug you filed as a place holder for redoing
bilinear blits
CR 7159455 : Nimbus scrollbar rendering glitch with xrender enabled on
i945GM
-phil.
On
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
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 Mario,
The patch looks good to me.
Thanks for taking a look.
Just wondering what is the impact of those two checks:
+ if (compClip.contains(transX1, transY1)
+ compClip.contains(transX2, transY2)) {
for the most common cases?
I wasn't able to measure any
Hi Clemens,
Looks fine should solve the problem. Perhaps it would have been nice to
calculate the interpolation with the clip but then you'd need to pay
attention to whether it was a complex clip or a simple rectangular one
and it may be better to do the delegation that you are doing now ...
11 matches
Mail list logo
