问题
I encountered this phenomenon in a mature application that I work on where the Tahoma font in WPF is much faster than Arial.
I built a test application to verify what I was seeing.
The test application has a TabControl with several TabItems. Each tab contains a DataGrid control and is populated with 18 columns. The grids/columns are all databound to the same viewmodel. The only difference whatsoever between the tabs are the fonts used. There are 1000 rows. The TextBlock sizes are fixed to the same sizes across the board.
When I attempt to drag the vertical scrollbar handle and vertically scroll, the performance varies dramatically between the Tahoma and Arial tabs. You know how a scrollbar handle lags behind where your mouse is while the drawing catches up, and each time it finishes drawing a screen, it immediately realizes you have already scrolled an entire screen or more futher, so it completely has to redraw again? With Tahoma, this happens pretty fast, "tick tick tick tick tick". It's not smooth scrolling by any means, but it is usable. With Arial, it's more like, "tick..........tick..........tick..........tick". Very noticable difference. I'd say it takes about 2-3 times as long per "tick".
I've played around with TextOptions.TextFormattingMode, TextOptions.TextRenderingMode, and Typography.NumeralAlignment, but the difference in performance remains.
Any ideas why this might be happening, and more importantly, if there are any pertinent settings that might alleviate the difference?
回答1:
I'm no font or WPF expert, but I found a hack-a-round that speeds up fonts and might lead somebody to a better answer. The slowdown is due an interaction between font construction and WPF rendering which is beyond my depth. My guess is that Microsoft hasn't optimized WPF for all font constructions, but alternatively maybe some font creation software doesn't optimize the fonts it generates.
I discovered that some fonts using OpenType-style tables are slow, while these same fonts using TrueType-style tables are fast. Note that file extension of the OpenType container (.otf) and TrueType container (.ttf) doesn't tell you what kind of table is inside, as both containers support both table styles (read "What's OpenType?" in FontForge documentation).
Slow fonts can be "fixed" by opening them in a font editing tool and exporting them with a TrueType table. This doesn't always work perfectly; at a glance it looks perfect for Open Sans, but broke kerning for Roboto. The error message I got seems to indicate that the required table size was larger than the TrueType table supports.
If you want to replicate my results using the free FontForge application, my procedure is:
1) Open the slow font (e.g. Arial, Roboto, Open Sans)
2) Element > Font Info > rename font to differentiate with slow font
3) File > Generate Font > select TrueType format, Options > deselect the "OpenType"
4) Test the 'fixed' font. I've found the fast/slow difference to be repeatable under any conditions: measuring rendering time several different ways, using DrawText or TextBlock, etc. One method of measuring the rendering time is given in this question.
回答2:
I have an example here...Seems to track down to Measurement instead of plain rendering...Bad Font-Measuring Performance under Windows 8.1
来源：https://stackoverflow.com/questions/25041233/why-does-the-tahoma-font-render-faster-than-arial-in-wpf