The latest LWJGL nightly build (3.0.0 #6) adds bindings to NanoVG. It looks like this:
* princec suddenly perks up
OOOH
… How does it perform? What’s it like compared to NV_path_rendering?
Cas 
[quote=“princec,post:2,topic:56015”]
Haven’t done much testing, other than porting the native demos. But it feels fast enough. The UI in the screenshot above is quite rich and only takes about a millisecond to render.
The API is verbose, like immediate mode rendering, but it batches commands internally and renders everything with a single shader.
[quote=“princec,post:2,topic:56015”]
They should be similar feature-wise, can’t say performance-wise. The obvious NanoVG advantage is that it works on all GPUs.
NV_path_rendering also claims to have some specific advantages wrt. accuracy of rendering (and goes to lengths to explain how everyone else’s implementation is slightly broken in various ways).
So I presume it’s rasterised on the CPU somehow? (Not dug into the source, but the docs don’t seem particularly forthcoming)
Cas
[quote=“princec,post:4,topic:56015”]
NV_path_rendering does analytical computations on quadratic segments directly, with more complex segments (cubic and arcs) approximated to quadratic. It also does it per-sample according to the documentation. NanoVG tessellates everything to linear segments, so it quite likely suffers from numerical instabilities like other implementations. I don’t think this matters much for game GUIs or other real-time scenarios, but it’ll probably be an issue for arbitrary SVG rendering.
[quote=“princec,post:4,topic:56015”]
No, there’s no rasterization, just tessellation. The C code feeds triangles to the shader, which are rendered in two passes (stencil, then cover), like NV_path_rendering.
There was a request to implement a NanoVG back-end using NV_path_rendering but it was rejected. See this reply.