<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 4, 2016 at 3:49 PM, Søren Sandmann <span dir="ltr"><<a href="mailto:soren.sandmann@gmail.com" target="_blank">soren.sandmann@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="h5">On Tue, Feb 16, 2016 at 4:45 PM, Bill Spitzak <span dir="ltr"><<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have a new version of this patch, which fixes a math error that<br>
caused it to produce too many samples at small sizes (large scales). I<br>
am not clear if I can submit a v14 of just this patch or I should<br>
instead submit a v14 of the entire patch series.<br></blockquote><div><br></div></div></div><div>I don't think this functionality belongs in pixman at all. Computing the number of subsamples is essentially a performance/quality tradeoff, which is something that cairo and other clients need to make for themselves. In general, pixman is not the place for heuristics; its API should be predictable and explicit.<br><br>So, NACK from me on this patch.</div></div></div></div></blockquote><div><br></div><div>The scale demo is almost useless without this as you have to adjust this every time you change the scale.</div><div><br></div><div>Most software I am familiar with use a fixed number of samples for the width of the filter, not per integer. This was an attempt to simulate that.</div><div><br></div><div>I guess the scale demo could do this math, though that makes it rather difficult to use the scale demo to figure out the best settings.</div><div><br></div></div></div></div>