Under a non-affine transform, or, in fact, any transform where the 'w' component of the (u,v,w) homogeneous source coordinate is not 1, the representation of u,v,w as 16.16 fixed point numbers will over/under flow on a regular basis even given fairly mundane transformations (like a simple keystone correction). I've fixed the intel driver to do these computations in floating point; I'm not sure we want to try to use fixed point here.
I believe this old bug may be somewhat related to http://lists.x.org/archives/xorg-devel/2014-August/043624.html and http://lists.x.org/archives/xorg-devel/2014-August/043644.html (it is rather inconvenient, but there are some tricks to make 16.16 fixed point accuracy sufficient for setting the keystone correction via xrandr tool). Pixman was originally based on the old Xorg code responsible for the XRENDER implementation and inherits the 16.16 fixed point limitations from it. And its primary purpose is to serve as a backend for XRENDER. There never was a real requirement to go beyond 16-bit coordinates and the pixman code is not ready for this yet. The http://cgit.freedesktop.org/pixman/commit/?id=e841c556d59ca0aa6d86eaf6dbf061ae0f4287de commit merely introduced an illusion of 32-bit coordinates support. Yes, it partially works by pure luck, but has a lot of problems and the users may encounter unpredictable results (see bug 69014). This ticket is basically asking for a pixman API extension to introduce floating point matrices. Yes, this could be useful for cairo and other users, but requires some non-trivial work to ensure correct functionality of the pixman pipeline and avoid performance regressions.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pixman/pixman/issues/15.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.