Fri 16 Sep 2016 02:06:29 PM UTC, comment #19:
Couple of comments before closing. Qt4 used to do its own font management, matching, caching, and configuration without fontconfig, which makes some sense because Qt works on Windows too. It is really hard to tell what you observe, it is complicated.
I want to improve ftbench and ftview so that they use only limited unicode range (-u 0x20-0x7f for basic latin or -u 4e00-9fff for CJK) because those are very different in complexity. We can also visualize missing unicode coverage in ftview with the same option.
|
Fri 16 Sep 2016 10:44:47 AM UTC, comment #18:
I have no experience with Qt or X11 programming, and besides, I like the v35 full hinting of DejaVu Sans Mono better than the v40 full hinting, so I'll just go back to the v35 interpreter and let someone else deal with this problem. Sorry for taking your time. You can close this report.
|
Fri 16 Sep 2016 05:30:07 AM UTC, comment #17:
It's not the job of FreeType to test X11, since this is beyond the scope of our library.
ftbench iterates over all glyphs, starting with the glyph index as specified by option `-i' (I've just committed some improvements to ftbench's man page for clarification).
I suggest to prepare a very small Qt example that exhibits the problem, then asking in a Qt expert forum for help.
|
Thu 15 Sep 2016 10:38:55 PM UTC, comment #16:
There's no significant difference between those benchmarks with the default settings, but this does not surprise me, as I am sure you would not have released 2.7 if this regression were evident in your default benchmark.
The benchmark is not representative of actual usage, though. For instance, I don't see any connection to the X11 server, and there is no transfer of the rendered bitmaps to a display surface. Also, does ftbench only load one glyph repeatedly, or does it load all glyphs in the font? It's entirely possible that the poor interpreter performance doesn't manifest on whichever glyph the benchmark is choosing to load and render.
Are there any externally visible differences (besides the actual pixel data) between the outputs of the two interpreters? For instance, does the v40 interpreter return subpixel-rendered bitmaps whose widths might not be a whole multiple of 3 pixels? I'm just trying to think of any reason why Qt could be chugging on the bitmaps returned by the v40 interpreter but not on those returned by the v35 interpreter. It's not as though Qt contains some kind of code like:
if (strcmp(FT_Get_Property("truetype:interpreter-version"), "40") == 0) {
QPainter::disableGlyphCache();
}
The choice of TrueType interpreter should be completely invisible to Qt, so I can't imagine why Qt would be doing anything differently depending on whether v35 or v40 is in use, other than if there is some material difference in the bitmaps that FreeType is returning.
|
Thu 15 Sep 2016 10:16:58 PM UTC, comment #15:
Just do `ftbench -I 40 consolas.ttf` for v40 and `ftbench -I 35 consolas.ttf` for v35. Hintfull is what FreeType does by default.
|
Thu 15 Sep 2016 08:13:15 PM UTC, comment #14:
I've downloaded and built ft2demos, and I have an ftbench that appears to work, but I cannot figure out which combination of load and render flags corresponds to fontconfig's "hintfull". I am setting FT_LOAD_NO_BITMAP | FT_LOAD_NO_AUTOHINT | FT_LOAD_TARGET_LCD and am using render mode 3 (FT_RENDER_MODE_LCD). This mostly matches my fontconfig configuration, but I can find no equivalent flags for hintstyle.
|
Thu 15 Sep 2016 07:22:05 PM UTC, comment #13:
My ftbench results for consola.ttf:
v40:
Load 3.347 us/op
Render 2.204 us/op
v35:
Load 3.206 us/op
Render 2.196 us/op
So the performace takes a slight hit, but no-where near two times.
|
Thu 15 Sep 2016 07:09:54 PM UTC, comment #12:
Why do you refuse to run direct test with ftbench to exclude all possible interference? You begin to notice that Qt5 might be involved while Gtk+ is ok, but you keep pointing at Freetype. C'mon!
|
Thu 15 Sep 2016 06:57:04 PM UTC, comment #11:
Okay, I've enabled full hinting for all fonts and restarted my desktop session.
There is no effect on the Konsole test. The v35 interpreter is still much faster than the v40 interpreter.
It's not just Konsole, though. Scrolling during a drag to select text in KWrite is now painfully laggy as well. When I run KWrite with the interpreter overridden to v35, then it is back to its usual snappy performance.
Interestingly, I observe no performance difference between v35 and v40 when scrolling in gitview, which is a Gtk+ application. I do see a very obvious visual difference, but the scrolling performance is the same.
So perhaps Qt 5 is misusing FreeType? If this is so, then I'm just going to rebuild FreeType 2.7 without the v40 interpreter and be done with this.
|
Thu 15 Sep 2016 06:38:24 PM UTC, comment #10:
Just to rule out some weird cache interaction, could you please enable full hinting globally for all fonts and without exceptions and then run the v40 tests again?
|
Thu 15 Sep 2016 06:23:54 PM UTC, comment #9:
I know rendered glyphs get cached. You are asserting that Konsole (or perhaps Qt 5) only caches glyphs when FreeType is running the v35 interpreter but not when it is running the v40 interpreter. Okay, I will open a bug report to Konsole with that information.
> Go v40 system-wide by default
I am running v40 system-wide by default, though it's irrelevant since my configuration does not hint any fonts except DejaVu Sans Mono, and the only application in which I use that font is Konsole. I am forcing Konsole to use the v35 interpreter (by passing FREETYPE_PROPERTIES=truetype:interpreter-version=35 to Konsole only) just to avoid this regression. The environment variable is unset throughout the rest of the system.
|
Thu 15 Sep 2016 06:13:35 PM UTC, comment #8:
Yes there is caching involved because rendering letter 'A' from scratch each time you need this glyph is silly. You cache v35 and you don't cache v40. I have no idea how, but this is not a bug in Freetype.
Go v40 system-wide by default, then run you tests again and be amused by the opposite result.
|
Thu 15 Sep 2016 06:01:33 PM UTC, comment #7:
> This is suspicious because there is no libfreetype.so in your v35 output at all. Where is it?
It's in there; it's just not in the first ten lines of output. (I excerpted for brevity in this bug report.)
See the attached opreport files. In particular, notice that TT_RunIns barely registers in the v35 report, way down at 0.0212% of samples, but TT_RunIns is at the top of the v40 report at 76% of samples.
> Perhaps you draw glyphs from cache outside freetype? You just didn't fill the cache with v40. This is not freetype fault.
How does this make sense? It's exactly the same code calling into FreeType. The only difference between runs is the FREETYPE_PROPERTIES environment variable. So this is a regression in FreeType: client code that formerly worked well now experiences a significant drop in performance.
If there is something new that client code needs to do in order to use the v40 interpreter efficiently, then you need to document that, and I will open a bug report for Konsole to get it done there.
(file #38518, file #38519)
|
Thu 15 Sep 2016 05:05:02 PM UTC, comment #6:
This is suspicious because there is no libfreetype.so in your v35 output at all. Where is it? Perhaps you draw glyphs from cache outside freetype? You just didn't fill the cache with v40. This is not freetype fault. You have to measure performance directly!
|
Thu 15 Sep 2016 04:49:50 PM UTC, comment #5:
I used OProfile to profile the Konsole test case with the v35 and v40 interpreters.
v35:
CPU: Core 2, speed 2394 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000
samples % image name symbol name
6054 10.4973 no-vmlinux /no-vmlinux
5438 9.4292 libQt5Core.so.5.6.1 QResourceRoot::findNode(QString const&, QLocale const&) const
3376 5.8538 libc-2.23.so _int_free
2760 4.7857 ld-2.23.so do_lookup_x
2379 4.1251 libc-2.23.so _int_malloc
2354 4.0817 libc-2.23.so malloc
1201 2.0825 libQt5Gui.so.5.6.1 qt_memfill32(unsigned int*, unsigned int, int)
v40:
CPU: Core 2, speed 2394 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000
samples % image name symbol name
261603 78.0087 libfreetype.so.6.12.6 TT_RunIns
6745 2.0113 no-vmlinux /no-vmlinux
5464 1.6293 libQt5Core.so.5.6.1 QResourceRoot::findNode(QString const&, QLocale const&) const
3908 1.1653 libfreetype.so.6.12.6 tt_loader_init
3468 1.0341 libc-2.23.so _int_free
2710 0.8081 ld-2.23.so do_lookup_x
2585 0.7708 libc-2.23.so malloc
This strongly suggests a performance regression in the v40 interpreter, does it not?
|
Thu 15 Sep 2016 03:21:54 PM UTC, comment #4:
We usually ask people to use ft2demo tools to demonstrate the bug. Can you please use ftbench for benchmarking to rule out any Konsole bugs?
Or, Nikolaus, can you post your results? Is it loading (likely) or rendering?
|
Wed 14 Sep 2016 06:56:00 AM UTC, comment #3:
> Does this only happen with that font or with all of them?
I don't have the patience to test every monospace font I have installed, but I tested a few, and the results follow. For each font, I tested each of the two interpreters three times, alternating between them, and I recorded the user-space CPU time in each run. (And of course I temporarily modified my fonts.conf to apply full hinting to all fonts.) The numbers in parentheses are the "fontversion" properties as reported by fc-match.
Consolas (349307)
v35: 0m5.185s 0m4.832s 0m5.306s
v40: 0m13.429s 0m19.432s 0m17.128s
Courier New (448922)
v35: 0m5.274s 0m4.763s 0m4.400s
v40: 0m10.560s 0m9.940s 0m10.539s
DejaVu Sans Mono (155320)
v35: 0m5.169s 0m4.760s 0m5.091s
v40: 0m8.708s 0m8.690s 0m10.654s
Liberation Mono (131072)
v35: 0m5.226s 0m4.652s 0m4.847s
v40: 0m8.902s 0m10.280s 0m9.917s
Ubuntu Mono (52428)
v35: 0m4.786s 0m4.801s 0m5.332s
v40: 0m6.021s 0m4.843s 0m6.302s
Clearly Consolas exhibits the largest difference among these five, so if you're trying to reproduce the issue, you may want to try that font. And compare it to Ubuntu Mono, which exhibits a much smaller difference.
I don't have ftbench. Where can I get it?
Is it possible that Konsole (via Qt 5) is triggering a pathological case in FreeType somewhere? Perhaps it is repeatedly causing some kind of cache to be discarded/invalidated and regenerated? This could explain why ftbench does not reproduce the issue, as ftbench presumably would not trash the caches between test samples.
|
Mon 12 Sep 2016 09:57:43 PM UTC, comment #2:
This is... curious. ftbench shows no difference with either interpreter. Uh, and gnome-terminal returns immediately upon spawning a terminal so I can't time it. And I don't want to download hundreds of megabytes for Konsole. Hrm. Anybody know some other benchmark?
Does this only happen with that font or with all of them?
|
Mon 12 Sep 2016 08:36:02 PM UTC, comment #1:
Nikolaus, please have a look!
|
Mon 12 Sep 2016 12:33:21 AM UTC, original submission:
I use DejaVu Sans Mono in Konsole with full hinting and no auto-hinting. I noticed a severe performance regression upon upgrading to FreeType 2.7.
$ fc-match -v 'DejaVu Sans Mono'
Pattern has 38 elts (size 48)
family: "DejaVu Sans Mono"(s)
familylang: "en"(s)
style: "Book"(s)
stylelang: "en"(s)
fullname: "DejaVu Sans Mono"(s)
fullnamelang: "en"(s)
slant: 0(i)(s)
weight: 80(i)(s)
width: 100(i)(s)
size: 12(f)(s)
pixelsize: 12.5(f)(s)
spacing: 100(i)(w)
foundry: "PfEd"(w)
hintstyle: 3(i)(w)
hinting: True(w)
verticallayout: False(s)
autohint: False(s)
globaladvance: True(s)
file: "/usr/share/fonts/dejavu/DejaVuSansMono.ttf"(w)
index: 0(i)(w)
outline: True(w)
scalable: True(w)
dpi: 75(f)(s)
rgba: 1(i)(w)
scale: 1(f)(s)
charset:
0000: 00000000 ffffffff ffffffff 7fffffff 00000000 ffffffff ffffffff ffffffff
0001: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffe00f f371ffcf
0002: ffffffff fffffff3 ffff303b ffffffff ffffffff fbffffff 7fcff3c3 000843ff
0003: ffffffff ffffffff 01000008 fcf00002 ffffd7f0 fffffffb ffff7fff ffff0003
0004: ffffffff ffffffff ffffffff 000c000c 0fff0000 0c0ffc3c ffff999f 03ffffff
0005: 3c030000 fffe0000 fe7fffff fffffffe 000006ff 00000000 00000000 00000000
0006: 882016c0 07fffffe 043fffff ce103fff 010200d9 40008210 00001000 03ff0000
000e: 00000000 80000000 00000000 00000000 fef02596 1bffecae 00003f00 00000000
0010: 00000000 00000000 00000000 00000000 00000000 00000000 ffff0000 1fffffff
001d: e0d00304 dfff7000 0fffffff 0980003c f8000020 feffffff 00000000 00000000
001e: ff0fffff ffff3fff fff03fff f3ffff0f 8bffffff 33c33003 3f003cc0 033fcf3f
001f: 3f3fffff ffffffff aaff3f3f 3fffffff ffffffff ffdfffff efcfffdf 7fdcffff
0020: ffff07ff f6ff804f 80000be0 fff30000 1fff7fff 273fffff 00000000 00000000
0021: 26e0e024 00004c54 fffb0100 00000000 ffff0200 ffffffff ffffffff ffffffff
0022: ffafffff 3ff03f89 fffffffe ffffe3ff ffffefff 013c003f fc03e07c 000083ff
0023: f33fff7f ffe009e3 ffffffff 27ffffff f8200f0f 00007fff 0000c000 00000000
0024: 00000000 00000008 00000000 00000000 00000000 00000000 00000000 00000000
0025: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
0026: ffffffff ff00ffff ffffffff ffffffff 1fff0fff 00030003 00000000 00000000
0027: fffff3de fffffeff 7f47afff 003ffffe ff100000 7ffeffff 10000064 00e00fc1
0029: 00000000 00000000 00000000 00000000 01800180 00000000 00000000 0c000800
002a: 00000001 00008000 00000000 00000c00 00000000 00000000 00000000 00000000
002b: 07fc3fe0 00000000 00000000 00000000 00000000 00000000 00000000 00000000
002c: 00000000 00000000 00000000 f6e1e010 00000000 00000000 00000000 00000000
002e: 81000000 0000403c 00000000 00000000 00000000 00000000 00000000 00000000
00a7: f87fff00 000000fc 00000000 00000000 00037e00 00000400 00000000 03000000
00f6: 00000000 00000000 00000000 00000000 00000000 00000000 00000020 00000000
00fb: 00000006 00000000 fffc0000 ffffffff c03ffc03 00003c00 00000000 f0000300
00fe: 00000000 00000000 00000000 ffdf0000 ffffffff ffffffff ffffffff 9fffffff
00ff: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 20000000
01d5: 00000000 00000000 04000000 00000000 00000000 00000000 00000000 00000000
01d6: 00000000 00000000 00000000 ffff0000 ffffffff 0000000f 00000000 00000000
01d7: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ffc00000
(w)
lang: aa|af|ar|ast|av|ay|az-az|az-ir|bm|be|bg|bi|bin|br|bs|bua|ca|ce|ch|chm|co|cs|cv|cy|da|de|el|en|eo|es|et|eu|fa|fi|fj|fo|fr|ff|fur|fy|ga|gd|gl|gn|gv|ha|haw|ho|hr|hu|hy|ia|ig|id|ie|ik|io|is|it|ka|kaa|ki|kk|kl|ku-am|kum|kv|kw|ky|la|lb|lez|ln|lt|lv|mg|mh|mi|mk|mo|mt|nb|nds|nl|nn|no|nr|nso|ny|oc|om|os|pl|pt|rm|ro|ru|sah|sco|se|sel|shs|sk|sl|sm|sma|smj|smn|so|sq|sr|ss|st|sv|sw|tk|tl|tn|to|tr|ts|tt|tw|tyv|uk|uz|ve|vo|vot|wa|wen|wo|xh|yap|yo|zu|ak|an|ber-dz|crh|csb|ee|fat|fil|hsb|ht|hz|jv|kab|kj|kr|ku-tr|kwm|lg|li|mn-mn|ms|na|ng|nv|pap-an|pap-aw|qu|quz|rn|rw|sc|sg|sn|su|ty|za(s)
fontversion: 155320(i)(s)
capability: "otlayout:DFLT otlayout:arab otlayout:cyrl otlayout:grek otlayout:lao otlayout:latn"(w)
fontformat: "TrueType"(w)
embeddedbitmap: False(w)
decorative: False(s)
lcdfilter: 1(i)(w)
namelang: "en"(s)
prgname: "fc-match"(s)
postscriptname: "DejaVuSansMono"(w)
color: False(w)
symbol: False(s)
$ time find /usr/src/linux/Documentation -type f -exec cat {} + >/dev/null
real 0m0.042s
user 0m0.009s
sys 0m0.030s
$ time FREETYPE_PROPERTIES=truetype:interpreter-version=35 konsole -e find -- /usr/src/linux/Documentation -type f -exec cat {} +
real 0m5.491s
user 0m5.166s
sys 0m0.913s
$ time FREETYPE_PROPERTIES=truetype:interpreter-version=40 konsole -e find -- /usr/src/linux/Documentation -type f -exec cat {} +
real 0m11.121s
user 0m10.820s
sys 0m1.041s
>> The new v40 interpreter uses TWICE the CPU time as the v35 interpreter!
DejaVu Sans Mono is the only font to which I apply hinting. The default on my system is no hinting, as I prefer the truer glyph forms of most fonts, even despite their being rendered a bit fuzzier on my low-DPI monitor.
Here is my ~/.config/fontconfig/fonts.conf:
<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
<dir>~/.fonts</dir>
<match target="font">
<edit mode="assign" name="embeddedbitmap">
<bool>false</bool>
</edit>
</match>
<match target="font">
<test name="family">
<string>DejaVu Sans Mono</string>
</test>
<test name="weight" compare="less_eq">
<const>normal</const>
</test>
<edit mode="assign" name="hinting">
<bool>true</bool>
</edit>
<edit mode="assign" name="hintstyle">
<const>hintfull</const>
</edit>
</match>
</fontconfig>
For now, I am forcing truetype:interpreter-version=35 in Konsole only, to avoid this regression.
A point of note: if I enable the auto-hinter, then the performance difference disappears. I presume this is because the native bytecode interpreter isn't being invoked at all, so the choice of interpreter version is irrelevant in this case.
|