我在一个成熟的应用程序中遇到过这种现象，我在WPF中使用Tahoma字体比Arial快得多。
我构建了一个测试应用程序来验证我所看到的内容。
测试应用程序有一个包含多个TabItem的TabControl。每个选项卡都包含一个DataGrid控件，并填充了18列。网格/列都是数据绑定到同一个视图模型。选项卡之间的唯一区别是使用的字体。有1000行。 TextBlock大小固定为相同的大小。
当我尝试拖动垂直滚动条手柄并垂直滚动时，Tahoma和Arial标签之间的性能会有很大差异。你知道当绘图赶上时滚动条手柄如何落后于鼠标位置，每次完成绘制屏幕时，它会立即意识到你已经滚动了整个屏幕或者更进一步，所以它必须再次重绘？使用Tahoma，这种情况发生得非常快，并且＃34;滴答滴答滴答滴滴答滴答＃34;。它无法通过任何方式平滑滚动，但它是可用的。使用Arial，它更像是，＆＃34; tick .......... tick .......... tick .......... tick＆＃ 34 ;.非常明显的区别。我说这需要大约2-3倍的时间＆＃34; tick＆＃34;。
我使用过TextOptions.TextFormattingMode，TextOptions.TextRenderingMode和Typography.NumeralAlignment，但性能上的差异仍然存在。
为什么会发生这种情况的任何想法，更重要的是，如果有任何相关的设置可能会缓解差异？
答案 0 :(得分：2)
我不是字体或WPF专家，但我发现了一个加速字体的黑客攻击，可能会让某人得到更好的答案。减速是由于字体构造和WPF渲染之间的相互作用，这超出了我的深度。我的猜测是微软没有为所有字体结构优化WPF，但也许某些字体创建软件不会优化它生成的字体。
我发现使用OpenType样式表的某些字体很慢，而使用TrueType样式表的这些相同字体很快。请注意，OpenType容器（.otf）和TrueType容器（.ttf）的文件扩展名不会告诉您内部是哪种表，因为两个容器都支持两种表样式（在{{3}中读取“什么是OpenType？” }）。
可以通过在字体编辑工具中打开慢速字体并使用TrueType表导出它们来“修复”慢速字体。这并不总是完美的;一眼就看出它对Open Sans来说是完美的，但却为Roboto打破了角色。我得到的错误消息似乎表明所需的表大小大于TrueType表支持。
如果您想使用免费的FontForge应用程序复制我的结果，我的程序是：
1）打开慢速字体（例如Arial，Roboto，Open Sans）
2）元素＆gt;字体信息＆gt;重命名字体以区分慢速字体
3）文件＆gt;生成字体＆gt;选择TrueType格式，选项＆gt;取消选择“OpenType”
4）测试'固定'字体。我发现快/慢差异在任何条件下都是可重复的：使用DrawText或TextBlock等几种不同的方式测量渲染时间。 测量渲染时间的一种方法在FontForge documentation中给出。
答案 1 :(得分：0)
我在这里有一个例子......似乎追踪到测量而不是普通渲染... Bad Font-Measuring Performance under Windows 8.1