<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 27, 2016 at 2:03 AM, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, 27 Apr 2016 09:56:44 +0100<br>
Emil Velikov <<a href="mailto:emil.l.velikov@gmail.com">emil.l.velikov@gmail.com</a>> wrote:<br>
<br>
> On 26 April 2016 at 19:12, Bill Spitzak <<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>> wrote:<br>
> > The old code is comparing pixman_fixed_48_16_t values to<br>
> > pixman_fixed_16_16_t values, thus it is checking for truncation of overflow<br>
> > values.<br>
> ><br>
> Indeed it does. I'll grep more before asking silly questions ;-)<br>
><br>
> > It would probably be better to clamp these overflowed values, like<br>
> > pixman_transform_point_31_16 is doing to clamp to the pixman_fixed_48_16<br>
> > result. Right now the result is an odd mix of clamping and modulus. A<br>
> > rewrite to go directly to clamped pixman_fixed_16_16 values would be even<br>
> > better.<br>
> ><br>
> Sounds like a plan. Sadly I doubt I'll get to it any time soon.<br>
<br>
</span>Wasn't the point of the boolean return from these functions to tell the<br>
caller to drop what it is doing because it cannot be done properly?<br></blockquote><div><br></div><div>Dropping a fill is a lot worse than trying to simulate it using the clamped path. It will produce a wrong result if one of the edges connected to a clamped point passes through the clip, but this often does not happen, and the transition to the wrong result is gradual as the point moves outside the clamped region.</div><div><br></div><div>More importantly the caller cannot do anything with the return values right now, as they are modulus MAX_16_16+1. Even the direction they are in is lost.</div><div><br></div></div></div></div>