<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 2, 2018 at 11:26 AM, Bryce Harrington <span dir="ltr"><<a href="mailto:bryce@osg.samsung.com" target="_blank">bryce@osg.samsung.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
(It'd still be interesting to see further refinements on the downscaling<br>
code, I'm sure there's still potential there for more optimization.<br>
Hopefully some day someone can look again at the convolution filter<br>
approach and see if it can get better integrated without causing<br>
test failures.)<br></blockquote><div><br></div><div>I have some plans for improving the downscaling, but they are three years old. The main problem is that my proposed changes to pixman were rejected and I had to give up after that, as I cannot see any possible way to improve this unless the filtering decisions are simplified and moved to pixman.</div><div><br></div><div>The basic problem is that the current filter api can define a single size of filter but the size and form of the filter depends on the transform algorithm. My proposed 2-pass algorithm, for instance, requires the filter in one direction to be parallel to an axis in the source image, and the filter in the second direction to be parallel to an axis in the destination image, and which one is chosen depends on the rotation and the dimensions of the image. Schemes that do multiple passes through intermediate images (ie mipmaps, Catmull-Rom 3-pass, closest-integer follwed by filtering, etc) put limits on the filters that can be used or how they are specified, as they must decompose into multple filters that are convolved. And for non-affine transforms the filter will vary for every single location.</div><div><br></div><div>Also just as a basic design criteria, I do not believe users of Cairo or Pixman are interested in anything other than whether filtering is happening, and perhaps choosing between "good" and "best" filtering to trade off speed. Limiting the api to simple keywords such as "good" and "best" will allow much more freedom for replacing and improving the filtering.</div><div><br></div><div>My proposal basically amounts to this:</div><div><br></div><div>1. Move filtering to Pixman and make the _GOOD and _BEST settings do something different and desirable. First proposal is to make them do exactly what Cairo is doing, running the existing filtering code (which is not 2-pass as it runs the 2 "passes" on every pixel, not reusing any previous results). Apparently there is a bug in the X so that pixman inside X will never receive the _GOOD or _BEST settings, for now I propose that it fall back to the image backend in these cases, to support this Cairo will still retain some redundant code to detect if _BILINEAR can be used so it does not have to do the fallback.</div><div><br></div><div>2. Add a new 2-pass algorithm to pixman and make _GOOD and _BEST run that (and possibly _BILINEAR as it is possible it will be faster than that for downscaling). The api is designed so that it is possible to replace this algorithm, in particular any kind of hardware-supported filtering might be far faster and should be allowed. This necessarily means that test image outputs can change, they will need to be changed when Cairo is changed to new algorithms. Add some non-affine tests to pixman.</div><div><br></div><div>3. Probably not strongly related, but add some non-affine transforms to source images to Cairo so it can use them.</div><div><br></div><div>Does anybody see any chance that this sort of change could be approved?</div><div><br></div></div></div></div>