NV_path_rendering alternative [closed]

Question

I just watched a very impressive presentation from Siggraph 2012:

http://nvidia.fullviewmedia.com/siggraph2012/ondemand/SS106.html

My question is, this being a proprietary Nvidia extension, what are the other possibilities to quickly renderer Bezier paths on GPU? Alternatively, is there any hope this will end-up as part of OpenGL standard? Is it possible to give any time estimate on when this eventually happens?

Do you know of any other (preferably open source) project dealing with GPU path rendering?

Edit: There is now a new "annex" to the original paper:

https://developer.nvidia.com/sites/default/files/akamai/gamedev/files/nvpr_annex.pdf

Answer 1

Ready made alternatives

NanoVG (https://github.com/memononen/nanovg) appears to have a little bit of traction (http://www.reddit.com/r/opengl/comments/28z6rf/whats_a_popular_vector_c_library_for_opengl/). So you could look at their implementation. I have not used NanoVG myself though and I'm mostly unfamiliar to its internals; what I do know is that they have specifically rejected using NV_path_rendering: https://github.com/memononen/nanovg/issues/25

As I mentioned already in a comment above, NV_path_rendering has now been implemented in Skia and appears to be courted by cairo too, see my comment below tjklemz's answer above for links on those details. One issue with NV_path_rendering is that it is somewhat dependent on the fixed-function pipeline, so a bit incompatible with OpenGL ES 2.0., but there's a workaround for that https://code.google.com/p/chromium/issues/detail?id=344330

I would stay away from anything OpenVG-related. The committee working on that has folded in 2011; it's now basically a legacy product/API. Most implementations of OpenVG (including ShivaVG) are also ancient and use fixed-function OpenGL according to https://github.com/memononen/nanovg/issues/113 If you really must use an OpenVG-like library, MonkVG appears the most well maintained [read as: the most recently abandoned] among the free ones (code: https://github.com/micahpearlman/MonkVG; 2010 announcement http://www.khronos.org/message_boards/showthread.php/6776-MonkVG-an-OpenSource-implementation-available). They claim it works on Windows, MacOS X, iOS and Android via OpenGL ES 1.1 and 2.0. The [fairly big] caveat is that MonkVG is not a full implementation of OpenVG; see the "TODO" section on their code page for what's missing.

I also found that a cairo (& pango) dev, Behdad Esfahbod, has written a new glyph (i.e. font) rendering library (https://code.google.com/p/glyphy/): "GLyphy is a signed-distance-field (SDF) text renderer using OpenGL ES2 shading language. [...] GLyphy [...] represents the SDF using actual vectors submitted to the GPU. This results in very high quality rendering." As far as I can tell it's not used in Cairo yet. (Behdad moved to Google [from Red Hat] and cairo hasn't seen releases in quite a while, so maybe GLyphy is gonna go into Skia instead, who knows...) I'm not sure how generalizable that solution is to arbitrary paths. (In the other direction, NV_path_rendering can also render fonts and with kerning, in case you didn't know that.) There is a talk at Linux.conf.au 2014 which you should definitely watch if you're interested in GLyphy: https://www.youtube.com/watch?v=KdNxR5V7prk If you're not familiar with the (original) SDF method, see http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf

I found a talk by a Mozilla dev which summarizes the common approaches in use today: https://www.youtube.com/watch?v=LZis03DXWjE#t=828 (The timestamp is to skip the intro part where he tells you what a GPU is.)

DYI (possibly)

By the way, a lot of the path-rendering stuff is command/state-change-intensive. I think that Mantle, DX12, and the OpenGL equivalents of that (mostly extensions http://gdcvault.com/play/1020791/) will probably improve that a fair bit.

I guess I should also mention that Nvidia has been granted (at least) four patents in connection with NV_path_rendering:

• https://www.google.com/patents/US8698837
• https://www.google.com/patents/US8698808
• https://www.google.com/patents/US8704830
• https://www.google.com/patents/US8730253

Note that there are something like 17 more USPTO docummets connected to these as "also published as", most of which are patent applications, so it's entirely possible more patents may be granted from those. Update on this: Google doesn't quite link all of them together, so there are some more that have been granted for sure:

• https://www.google.com/patents/US8786606
• https://www.google.com/patents/US8773439

I'm not sure under what terms they are willing to license those...

I found a really nice FAQ by Kilgard himself for "what's special about vector-graphics/path-rendering" which is unfortunately buried somewhere in the OpenGL forum http://www.opengl.org/discussion_boards/showthread.php/175260-GPU-accelerated-path-rendering?p=1225200&viewfull=1#post1225200. This is quite a useful reading for anyone considering quick/hack alternative solutions.

There is also one new thing in Direct3D 11.1 that's possibly useful because Microsoft used it to improve their Direct2D implementation with it in Windows 8; it's called target independent rasterization (TIR). I don't know much about it other than that Microsoft has a patent application on it. http://www.google.com/patents/US20120086715 The catch is that only AMD GPUs seem to actually support it per this "war of words" http://www.hardwarecanucks.com/news/war-of-words-between-nvidia-and-amd-over-directx-11-1-support-continues/

Adoption

I don't have a crystal ball as to when NVpr is going to get adopted by non-Nvidia, but I think they are pushing it quite hard. The OpenGL 4.5 Nvidia presentation has pretty much been taken over by that--at least as far as demos ware concerned, which I thought was a bit silly (since it's not part of OpenGL 4.5 core). Neil Trevett also covered NVpr more than once (e.g. https://www.youtube.com/watch?v=eTdLwfOLoG0#t=2095) and Adobe Illustrator beta 2014 is using it as well as Google's Skia.

Answer 2

what are the other possibilities to quickly renderer Bezier paths on GPU?

In-Situ tesselation of a set of control points into convex patches defines by a triangular hull using a tesselation and/or geometry shader. Then passing the curvature parameters to a fragment shader that performs a per-fragment test if the fragment is within the boundaries of each patch and discarding it otherwise.

If an approximation is in order then just tesselating into a triangular mesh is in order.

Answer 3

ShivaVG is an open source alternative for path rendering. See this Stack Overflow question for a list of OpenVG implementations: Best OpenVG Implemenatation

Basically, you have a few options: use an OpenVG implementation (like ShivaVG), use an OpenGL implementation or extension (like the NV_path_rendering), or use something else entirely, like Direct2D.

However, other alternatives to NV_path_rendering cannot even come close to its feature set and the quality of its render. NV_path_rendering can natively handle fonts (which is a big deal—without fonts, you're toast), scale and so forth in true perspective (try that in Illustrator!), mix well with 3D, use sRGB, use fragment shaders, and does all this incredibly fast. It also implements user-interaction, which OpenVG does not specify AFAIK.

Uniquely, NV_path_rendering does not invent a new standard. Rather, it implements several industry standards, such as PostScript and SVG, with a focus on quality and speed (it's rare to have them both) that you cannot currently find anywhere else.

(Plus, Mark Kilgard is the project lead. C'mon. The guy's brilliant.)

---

Will it become standard? Hard to know. As for what to use, it really depends on your purpose/need at this point. Looking for quality path rendering for an app? NV_path_rendering for sure. Looking for basic resolution independent graphics in apps (esp. mobile)? OpenVG might be better. It's too bad that Nvidia's solution is not completely portable, but I wouldn't shy from using it. I'd prefer having a quality solution; sometimes portability isn't everything.

Nvidia has compared their solution to OpenVG and found that OpenVG doesn't provide too much benefit, unfortunately. So, yes, there might be hope for it to become a standard. But, since according to IBM everything in the future will be embedded, perhaps it would be better to hope for it to be open, instead of wanting more standards.

"The nice thing about standards is that you have so many to choose from." -- Computer Networks, 2nd ed., p. 254

---

For more info on NV_path_rendering features, I recommend looking at this: An Introduction to NV_path_rendering.