> + * >> + * and the destination coordinates are (n + 0.5, m + 0.5). >> Then >> + * the transformed x coordinate is: >> + * >> + * tx = t00 * (n + 0.5) + t01 * (m + 0.5) + t02 >> + * = t00 * n + t01 * m + t02 + (t00 + t01) * 0.5 >> > > 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. >
We use tx in one other place in pixman, so I kept it that way. + /* FIXME: there are some affine-test failures, showing that >> + * handling of BILINEAR and NEAREST filter is not quite >> + * equivalent when getting close to 32K for the >> translation >> + * components of the matrix. That's likely some bug, but >> for >> + * now just skip BILINEAR->NEAREST optimization in this >> case. >> + */ >> + pixman_fixed_t magic_limit = pixman_int_to_fixed (30000); >> + if (image->common.transform->matrix[0][2] <= magic_limit >> && >> + image->common.transform->matrix[1][2] <= magic_limit >> && >> + image->common.transform->matrix[0][2] >= -magic_limit >> && >> + image->common.transform->matrix[1][2] >= -magic_limit) >> + { >> + flags |= FAST_PATH_NEAREST_FILTER; >> + } >> > > Can this be tested to see if the bug still exists? > > 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. > 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. I have addressed your other comments in the new series that I just sent out. Søren
_______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pixman