freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] Pixel Differences after 2ea511eed8 and 7a81b63abc2b3


From: Alexei Podtelezhnikov
Subject: Re: [ft-devel] Pixel Differences after 2ea511eed8 and 7a81b63abc2b3
Date: Fri, 24 May 2019 09:42:17 -0400

> 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.

Dominik,

You point is well taken, but benchmarking FreeType is hard even
considering that rendering is the bottleneck. This is because there is
often too many moving parts, too many simple and incredibly complex
fonts to choose from, too many use cases. No single number is probably
sufficient, instead I look at each individual components: flattening a
single Bezier segment (cubic and conic separately), rendering a line,
composing the image, etc. I actually use 'perf to see how the shares
of a function of interest changes. This is incredibly tedious work. I
do use "ftbench -b c" too to get an integral number (it is not like we
do not have anything, we do have ftbench). You are welcome to hit me
over the head if "ftbench -b c" deteriorates, so that your complains
are also data driven.

Case in point: Bezier bisections have not been touched in more than 10
years. I myself could not imagine that I would improve them by 20-30%.
Then I spent an evening tweaking them and probably (just probably)
found something that makes sense in C and performs well. Do you think
I would find somebody to talk to meanwhile? Do you think this is more
interesting than discussing SVG? I doubt. This is quite boring. I only
like to work on FreeType rendering because it is so reach in linear
algebra, not because I enjoy programming. Bezier flattening is about
linear algebra. Shall we go into the weeds? Most algorithms that you
can find are all correct subject to a certain threshold condition. I
think what I committed is incredibly simple computationally, so that
it will be hard to beat in performance. It is again my gut feeling
with a couple of percents in performance improvement.

The previous algorithms survived for 6-10 years. I don't think this is
too frequent to rebase your incredibly useful testing framework.

Alexei



reply via email to

[Prev in Thread] Current Thread [Next in Thread]