[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freetype-devel
Subject:    Re: Rendering performance comparison between FreeType 2.6.5 and current `master`
From:       Alexei Podtelezhnikov <apodtele () gmail ! com>
Date:       2022-09-05 20:44:57
Message-ID: CAJU=AjU970rAobWz5At3EF70DqJX9rUbihU9G48qGj+4XK-V5w () mail ! gmail ! com
[Download RAW message or body]

On Mon, Sep 5, 2022 at 1:12 PM Anurag Thakur
<anurag105csec21@bpitindia.edu.in> wrote:
> (notomono_comp.png)
> (notomono_comp_expanded.png)

These look very good indeed. The almost linear shape at the small
sizes comes from the dominant dependence on the glyph perimeter, more
or less. The convex shape apparent in the expanded range comes from
the 2D image matrix operations.

> I also ran the perf utility, results attached (.data files are the binaries \
> generated by perf, .txt files are human readable output generated by perf report)

These look appropriate too.

> At small sizes, the "TT_RunIns" function dominates, while at larger ones, the \
> render line function is prominent

TT_RunIns is the TrueType instruction interpreter. These are unlikely
to have noticeable effects on rendering performance and can be
disabled by passing FT_LOAD_NO_HINTING, `ftbench -f 0x2...`

> Other notable functions are ` Ins_IUP.constprop.0`,`_iup_worker_interpolate` which \
> are not prominent at large sizes

Just a common and expensive interpolation instruction. It will also
disappear with `-f 0x2`.

> 10.69%  lt-ftbench  libfreetype.so.6.18.3  [.] gray_render_line
> 4.28%  lt-ftbench  libfreetype.so.6.18.3  [.] gray_set_cell

These two are the workhorses of the rendering algorithm. This *is*
what takes the bulk of rendering time, not the curve flattening, not
the sparse-to-dense matrix conversions.

Alexei


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic