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 t
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 al
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,
> 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
opti
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,
Ple
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 4/7/12
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
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 ...
-ph
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,
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 :
> Hi,
>
> Please take
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
11 matches
Mail list logo
