我正在开发一个基于canvas的应用程序（linkurious.js），进行了性能分析后发现目前主要瓶颈是文本渲染。
目前，我使用fillText()来渲染文本，但有以下疑问：
- 使用位图字体是否更高效？
- 距离场（Distance fields）是否更好？
- 浏览器是否已经优化了字体渲染，使得我不需要自己尝试去超越它们？
在画布中优化文本渲染——TrueType字体与位图字体的渲染速度比较。
4
- damio
1个回答
6
首先，渲染文本尤其是基于矢量的文本是很困难的。即使使用基于WebGL的实现，你可能也无法打败浏览器，因为浏览器字体渲染已经被优化得相当好了（浏览器从1994年开始就一直在渲染字体）。
理论上，如果文本不变，浏览器/字体引擎应该重新创建和缓存所有已呈现字形到GPU内存中，然后只需从那里将它们作为位图传输出来。
所以，如果文本是性能瓶颈，则位图字体成为一种选择。缺点有很多，但速度不是其中之一。毕竟，这正是90年代的计算机如何在屏幕上呈现任何文本的方式。
- Mikko Ohtamaa
6
那么，使用位图字体会比预渲染字体的GPU缓存更好吗？ - damio
2理论上不应该。但这取决于您正在呈现什么类型的文本，有多少文本，以及它有多频繁地更改。唯一的方法是编写代码并在不同的浏览器中进行基准测试，才能知道确切情况。 - Mikko Ohtamaa
谢谢，最后一个问题：我可以直接使用位图字体（例如 .ttf）吗？还是应该使用自己的渲染器和预生成的位图字体纹理集？ - damio
1你需要在离线或应用程序启动时预先生成TTF -> 位图精灵表。 - Mikko Ohtamaa
3省去麻烦，不要使用精灵表字体。为您想要显示的文本创建缓冲区，将文本绘制到该缓冲区中，然后仅将该缓冲区呈现到画布上。当渲染文本仅发生一次时，它并不慢，而是在每帧调用fillText时才会出现性能问题。 - ericjbasti
1历史记录：我找到了真正的瓶颈：为每个文本设置“context.font”使渲染变慢了2倍。 - damio
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接