<div dir="ltr"> <div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+            *<br>
+            * and the destination coordinates are (n + 0.5, m + 0.5). Then<br>
+            * the transformed x coordinate is:<br>
+            *<br>
+            *     tx = t00 * (n + 0.5) + t01 * (m + 0.5) + t02<br>
+            *        = t00 * n + t01 * m + t02 + (t00 + t01) * 0.5<br></blockquote><div><br></div></span><div>I would use u,v rather than tx,ty for the source coordinates. More complex analysis of transforms gets very hard to read unless the variables are kept to one letter.</div></div></div></div></blockquote><div><br></div><div>We use tx in one other place in pixman, so I kept it that way.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+               /* FIXME: there are some affine-test failures, showing that<br>
+                * handling of BILINEAR and NEAREST filter is not quite<br>
+                * equivalent when getting close to 32K for the translation<br>
+                * components of the matrix. That's likely some bug, but for<br>
+                * now just skip BILINEAR->NEAREST optimization in this case.<br>
+                */<br>
+               pixman_fixed_t magic_limit = pixman_int_to_fixed (30000);<br>
+               if (image->common.transform->matrix[0][2] <= magic_limit  &&<br>
+                   image->common.transform->matrix[1][2] <= magic_limit  &&<br>
+                   image->common.transform->matrix[0][2] >= -magic_limit &&<br>
+                   image->common.transform->matrix[1][2] >= -magic_limit)<br>
+               {<br>
+                   flags |= FAST_PATH_NEAREST_FILTER;<br>
+               }<br></blockquote><div><br></div></span><div>Can this be tested to see if the bug still exists?</div><div><br></div><div>The comment should be reworded to point out that the bug is in the BILINEAR code, not the NEAREST code, but this patch is needed to not have the NEAREST case "fix" the ones that are broken and thus make the fast path output different.</div></div></div></div></blockquote><div><br></div><div>Sure, this can be done. And in fact, it appears this bug doesn't exist anymore. However, I think such a change belongs in a different patch set.<br></div><br></div><div class="gmail_quote">I have addressed your other comments in the new series that I just sent out.<br><br><br></div><div class="gmail_quote">Søren<br></div><div class="gmail_quote"><br></div></div></div>