我刚刚观看了 Siggraph 2012 上的一个非常令人印象深刻的演示：
http://nvidia.fullviewmedia.com/siggraph2012/ondemand/SS106.html
我的问题是，这是一个专有的 Nvidia 扩展，在 GPU 上快速渲染贝塞尔路径的其他可能性是什么？或者，是否有希望最终成为 OpenGL 标准的一部分？是否有可能给出最终发生的时间估计？
你知道处理 GPU 路径渲染的任何其他（最好是开源）项目吗？
编辑：原始论文现在有一个新的“附件”：
https://developer.nvidia.com/sites/default/files/akamai/gamedev/files/nvpr_annex.pdf
NanoVG（https://github.com/memononen/nanovg）似乎有一点吸引力（http://www.reddit.com/r/opengl/comments/28z6rf/whats_a_popular_vector_c_library_for_opengl/）。所以你可以看看他们的实现。不过，我自己并没有使用过 NanoVG，而且我对它的内部结构也很陌生。我所知道的是他们已经明确拒绝使用NV_path_rendering：https ://github.com/memononen/nanovg/issues/25
正如我在上面的评论中已经提到的那样，NV_path_rendering 现在已经在 Skia 中实施，并且似乎也受到了 cairo 的青睐，请参阅上面 tjklemz 答案下方的评论以获取有关这些详细信息的链接。NV_path_rendering 的一个问题是它在某种程度上依赖于固定功能管道，因此与 OpenGL ES 2.0 有点不兼容。但是有一种解决方法https://code.google.com/p/chromium/issues/detail ?id=344330
我会远离任何与 OpenVG 相关的东西。从事这项工作的委员会于 2011 年解散；它现在基本上是一个遗留产品/API。OpenVG 的大多数实现（包括 ShivaVG）也很古老，并且根据https://github.com/memononen/nanovg/issues/113使用固定功能的 OpenGL如果你真的必须使用类似 OpenVG 的库，MonkVG看起来最好在免费的（代码：https ://github.com/micahpearlman/MonkVG ；2010 年公告http://www.khronos.org/message_boards/showthread.php/6776-MonkVG -an-OpenSource-implementation-available）。他们声称它可以通过 OpenGL ES 1.1 和 2.0 在 Windows、MacOS X、iOS 和 Android 上运行。[相当大的] 警告是 MonkVG 不是 OpenVG 的完整实现。有关缺少的内容，请参阅其代码页上的“TODO”部分。
我还发现 cairo (& pango) 开发人员 Behdad Esfahbod 编写了一个新的字形（即字体）渲染库（https://code.google.com/p/glyphy/）：“GLyphy是使用 OpenGL ES2 着色语言的有符号距离场 (SDF) 文本渲染器。[...] GLyphy [...] 使用提交给 GPU 的实际向量来表示 SDF。这导致了非常高质量的渲染。”据我所知，它还没有在开罗使用。（Behdad [从 Red Hat] 搬到了谷歌，而且 cairo 已经有一段时间没有看到发布了，所以也许 GLyphy 会去转而使用 Skia，谁知道...）我不确定该解决方案对任意路径的推广程度。（在另一个方向上，NV_path_rendering 也可以渲染字体和字距调整，以防你不知道。）那里是 Linux.conf.au 2014 上的一次演讲，如果您对 GLyphy 感兴趣，您绝对应该观看：https ://www.youtube.com/watch?v=KdNxR5V7prk如果您不熟悉（原始）SDF方法见http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf
我发现了一个 Mozilla 开发人员的演讲，总结了当今使用的常用方法：https ://www.youtube.com/watch?v=LZis03DXWjE#t=828 （时间戳是跳过他告诉你什么的介绍部分GPU 是。）
顺便说一句，很多路径渲染的东西都是命令/状态更改密集型的。我认为 Mantle、DX12 和它的 OpenGL 等价物（主要是扩展http://gdcvault.com/play/1020791/）可能会改善这一点。
我想我还应该提到，Nvidia 已获得（至少）四项与 NV_path_rendering 相关的专利：
请注意，还有大约 17 份与这些相关的 USPTO 文件“也发布为”，其中大部分是专利申请，因此完全有可能从这些文件中授予更多专利。对此的更新：谷歌并没有将所有这些链接在一起，所以肯定还有一些被授予：
我不确定他们愿意在什么条件下许可这些...
我发现 Kilgard 自己的一个非常好的常见问题解答，关于“矢量图形/路径渲染的特别之处”，不幸的是它被埋在 OpenGL 论坛http://www.opengl.org/discussion_boards/showthread.php/175260-GPU的某个地方-加速路径渲染？p=1225200&viewfull=1#post1225200。对于任何考虑快速/破解替代解决方案的人来说，这都是一本非常有用的读物。
Direct3D 11.1 中还有一项新功能可能很有用，因为 Microsoft 使用它来改进他们在 Windows 8 中的 Direct2D 实现；它被称为目标独立光栅化（TIR）。除了微软有一个专利申请外，我对此知之甚少。http://www.google.com/patents/US20120086715问题是只有 AMD GPU 似乎真正支持它，因为这个“口水战” http://www.hardwarecanucks.com/news/war-of-words-在-nvidia-and-amd-over-directx-11-1-support-continues/之间
我不知道 NVpr 何时会被非 Nvidia 采用，但我认为他们正在努力推动它。OpenGL 4.5 Nvidia 演示文稿几乎已经被它取代了——至少就演示软件而言，我认为这有点愚蠢（因为它不是 OpenGL 4.5 核心的一部分）。Neil Trevett 还不止一次地介绍了 NVpr（例如https://www.youtube.com/watch?v=eTdLwfOLoG0#t=2095）， Adobe Illustrator beta 2014和 Google 的 Skia 也在使用它。
ShivaVG是路径渲染的开源替代方案。有关 OpenVG 实现的列表，请参阅此 Stack Overflow 问题：Best OpenVG Implemenatation
基本上，您有几个选择：使用OpenVG实现（如ShivaVG），使用 OpenGL 实现或扩展（如NV_path_rendering），或完全使用其他东西，如Direct2D。
但是，NV_path_rendering 的其他替代方案甚至无法接近其功能集和渲染质量。NV_path_rendering 可以原生处理字体（这很重要- 没有字体，你是吐司），以真实视角缩放等等（在 Illustrator 中尝试！），与 3D 混合，使用 sRGB，使用片段着色器，并且确实这一切都快得令人难以置信。它还实现了用户交互，OpenVG 没有指定 AFAIK。
独特的是，NV_path_rendering没有发明新标准。相反，它实现了几个行业标准，例如PostScript和SVG，重点是质量和速度（很少同时拥有这两者），这是您目前在其他任何地方都找不到的。
（另外，Mark Kilgard 是项目负责人。来吧。这家伙很聪明。）
会成为标准吗？很难知道。至于使用什么，这实际上取决于您此时的目的/需求。寻找应用程序的高质量路径渲染？NV_path_rendering 肯定。在应用程序（尤其是移动设备）中寻找基本分辨率无关的图形？OpenVG 可能会更好。Nvidia 的解决方案不是完全可移植的，这太糟糕了，但我不会回避使用它。我更喜欢有质量的解决方案；有时可移植性并不是一切。
Nvidia 将他们的解决方案与 OpenVG 进行了比较，不幸的是，OpenVG 并没有提供太多好处。所以，是的，它可能有希望成为一个标准。但是，因为根据 IBM 的说法，未来一切都将被嵌入，也许希望它是开放的，而不是想要更多的标准。
“标准的好处是你有很多可供选择。” ——《计算机网络》，第 2 版，p。254
有关NV_path_rendering 功能的更多信息，我建议您查看：An Introduction to NV_path_rendering。
在 GPU 上快速渲染贝塞尔路径的其他可能性是什么？
使用细分和/或几何着色器将一组控制点原位细分为凸块，由三角形外壳定义。然后将曲率参数传递给片段着色器，如果片段在每个补丁的边界内，则执行每个片段的测试，否则将其丢弃。
如果近似是有序的，那么只需镶嵌成三角形网格就可以了。