Hi Alexei, On Tue, May 21, 2019 at 6:49 AM Alexei Podtelezhnikov <apodt...@gmail.com> wrote:
> > > On Thu, May 16, 2019 at 2:11 PM Dominik Röttsches <dr...@google.com> > wrote: > b) I would prefer 7a81b63abc2b3da0d7f0950f69377d2b3f54b0fb to be reworked > so it doesn't cause pixel differences if possible, or reverted. Similarly > with the current reasoning, I do not find > 2ea511eed81770f423544525adebf7f954b8be93 a change that is strictly required > or justified. > > Dominik, > > I have just committed the benchmarking numbers: Bezier bisections are > faster by 20-30%, which ultimately translates to 2-3% of rendering speed. > The other change gives 1% more. Not much right? I have been squeezing these > percentage points over past 6 years and it adds up to about 30% by now. > Considering that FT_Render_Glyph is called at least 10^12 times globally > daily, it is important. > > IMHO, the bit-level consistency that you are asking is flawed in the case > of font rasterization. For what it is worth, rasterization is > approximation, i.e, Bézier curves are flattened. There is so many > *correct* ways to do it looking for that performance. Not everything has to > be a bug fix, not every bit matters. > I appreciate your knowledgeable work on performance in this area. I am not asking for strict bit level consistency but I am asking to weigh pixel rasterisation changes against the effects on embedding projects and workflows. Neither have I claimed the changes are distinctly incorrect. I am asking for a tighter workflow, unit testing in FreeType and FreeType development catching pixel differences early before causing redundant and multiplied efforts in downstream embedded projects and to evaluate a performance tweak against the costs of pixel changes. Similarly, if FreeType had performance tracking bots it would be easy to follow the benefits of a performance improvement and such decisions would be come more data driven. Committing something with a brief message which can be paraphrased as "looks better to me" without benchmarks and without a discussion on the mailing list or a bug report as further context is in my opinion not sufficient to justify the headache of re-evaluating thousands of test baselines, with the risk of missing actual failures - as we explained before. This applies to PDFium, Chromium and I am sure more projects. The fact that FreeType does not unit test or perform try bot runs in CI makes it easy to ignore the additional work that changes like this do cause - which leads to a biased, project local evaluation of the value of such a CL. I am not sure what you mean by "I have just committed the benchmarking numbers" - did you publish them somewhere? In any event, you seem to have the benchmarking numbers - why not put such figures with reproduction steps in to the commit message or in an issue on the issue tracker next time, ideally before the commit? Ben Wagner has helpfully set up a FreeType autoroller into Chromium which will soon allow us to track differences on individual changes and alert us earlier when we start to see breakage - this will notify us earlier about regressions and pixel failures and we can discuss such issues sooner before running into the set of issues that we're facing with rolling from 2.10 to ToT. In the meantime, I understood from Werner's comment in https://savannah.nongnu.org/bugs/?56321#comment6 that my request will be taken into consideration in future similar changes. Dominik
_______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
