SVG rendering with OpenGL (and OpenGL ES)

Question

I am currently studying the possibility of rendering vector graphics from an SVG file using OpenGL and OpenGL ES. I intend to target Windows and Android. My ideal solution would be to have a minimal C library that generates a polygon triangulation from a given SVG file. Then it will generate standard OpenGL or OpenGL ES calls, and also use a display list or vbo to optimize when redrawing. I would just draw a display list to draw a vector image after translation and rotation, which allowed me to mix this with other OpenGL calls.

So far I see that the suggestions are to use QT or Cairo first. - This is not an option, given that I want to manage my own OpenGL context without bloated libraries (in the context of what I'm trying to achieve). And it is not suitable for Android.

The second option is to use libraries that display texture. Although this may be good for static vector graphics, it is not an efficient or feasible option for games where scaling and rotation often occur.

Thirdly, there is the possibility of using OpenVG. There are some versions of OpenVG for OpenVG (ShivaVG, etc.), but I have not yet found a library that is capable of generating the corresponding OpenVG calls from a given SVG file at runtime, and I do not see how to optimize this as we could wish with display list or vbo.

All three methods have limitations. I think the most promising option is to use an OpenVG implementation if no other solution exists. So my question is: are there libraries that do what I want, or are close to what I want? If not, is there a good reason why not? And would it be better to try to do it from scratch?

Answer 1

From http://shivavg.svn.sourceforge.net/viewvc/shivavg/trunk/src/shPipeline.c?revision=14&view=markup :

static void shDrawVertices(SHPath *p, GLenum mode) { int start = 0; int size = 0; /* We separate vertex arrays by contours to properly handle the fill modes */ glEnableClientState(GL_VERTEX_ARRAY); glVertexPointer(2, GL_FLOAT, sizeof(SHVertex), p->vertices.items); while (start < p->vertices.size) { size = p->vertices.items[start].flags; glDrawArrays(mode, start, size); start += size; } glDisableClientState(GL_VERTEX_ARRAY); } 

Therefore, it uses VBO. Therefore, I propose to create my own SVG parser / use the pre-made one and forward the calls to ShivaVG.

You still have the problem that ShivaVG is in C (and not in Java) and is creating an opengl context (and not opengles if I read the code correctly). Therefore, even if you compile it using the Android NDK, you will have to change the code (for example, I saw several glVertex3f, but they do not seem to be very necessary ... I hope for the best). Another option, of course, is porting code from C to Java. Maybe not as painful as you might have imagined.

Good luck

Answer 2

My answer will be devoted to displaying vector graphics with OpenGL in general, because all solutions to this problem can support, in particular, trivially SVG, although none of them supports animated SVG (SMIL). Since nothing is said about the animation, I assume that the question implies only static SVGs.

Firstly, I wouldn’t bother with anything OpenVG, even with MonkVG, which is probably the most modern, although incomplete. The OpenVG committee was formed in 2011, and most, if not all, implementations are fault tolerant or, at best, outdated software.

Since 2011, the current state is Mark Kilgard’s child, NV_path_rendering , which is currently only an extension of the vendor (Nvidia), you guessed it from his name. It has a lot of materials:

• https://developer.nvidia.com/nv-path-rendering Nvidia hub, but some materials on the landing page are not the latest
• http://developer.download.nvidia.com/devzone/devcenter/gamegraphics/files/opengl/gpupathrender.pdf Siggraph 2012 Document
• http://on-demand.gputechconf.com/gtc/2014/presentations/S4810-accelerating-vector-graphics-mobile-web.pdf GTC 2014 Presentation
• http://www.opengl.org/registry/specs/NV/path_rendering.txt official doc extension

Of course, you can download SVG and such https://www.youtube.com/watch?v=bCrohG6PJQE . They also support PostScript syntax for paths. You can also mix route rendering with other OpenGL (3D) materials, as shown on the page:

• https://www.youtube.com/watch?v=FVYl4o1rgIs
• https://www.youtube.com/watch?v=yZBXGLlmg2U

NV_path_rendering is now used by the Google Skia library behind the scenes when it is available. (Nvidia introduced its code at the end of 2013 and 2014.) It seems that one of the developers of Cairo (who is also an Intel employee) is http://lists.cairographics.org/archives/cairo/2013-March/024134.html , although I don't yet know of any specific attempts to use cairo for NV_path_rendering.

NV_path_rendering has a few minor dependencies on a fixed pipeline, which can be a nuisance in OpenGL ES. This issue is recorded in the official extension document mentioned above. For a workaround, see, for example, what Skia / Chromium did: https://code.google.com/p/chromium/issues/detail?id=344330

An upstart that has even less (or completely none) supplier support or academic brilliance, NanoVG , which is currently being developed and maintained. ( https://github.com/memononen/nanovg ) Given the number of 2D libraries on top of OpenGL that come and go over time, you make a big bet using something not supported by a major provider, in my humble opinion.

Answer 3

Mark the MonkVG implementation of OpenVG as an API on top of OpenGL ES.

Also, for SVG rendering on top of the OpenVG (MonkVG) MonkSVG check .

MonkVG was created for iOS, OSX, and Android.

I am the author of both libraries and will be happy to answer any questions.

Answer 4

I am currently studying the possibility of rendering vector graphics from an SVG> file using OpenGL and OpenGL ES. I intend to target Windows and Android. My ideal solution would be to have a minimal C library that generates a polygon triangulation from a given SVG file. It will then generate standard OpenGL or OpenGL ES calls and use the display list or vbo to optimize when redrawing. I would simply draw a display list to draw a vector image after translation and rotation, which allows me to mix this with other OpenGL> calls.

If you want to convert SVG vector shapes to OpenGL | ES, I suggest doing the parser and the logic yourself. Please note that SVG is a huge specification with various features such as drawing servers (gradients, templates ...), links, filters, cropping, font handling, animation, scripts, links, etc.

If you need full svg support, then there is a http://code.google.com/p/enesim library called egueb (and especially esvg) that uses enesim (a rendering library that has software and opengl) for drawing. In most cases, it uses shaders, and everything is visualized in texture, the library is very flexible, allowing you to adapt to your specific needs, for example, change the rendered scene, transform it, etc. Since the gl drawing is always done in texture.

So far I see that the suggestions are to use QT or Cairo first. - This is not an option considering that I want to manage my own OpenGL context without bloated libraries (in the context of what I'm trying to achieve). And it is not suitable for Android.

The second option is to use libraries that display texture. Although this may be good for static vector graphics, it is not an efficient or feasible option for games where scaling and cornering often occur.

In the particular case, gl backend enesim does not create GLX (or any other window-dependent context), you must provide it, so it adapts perfectly to your situation, since it uses only GL calls.

The only drawback is that the library is not finished yet in terms of gl support or full support for the SVG specification, but depending on your needs, it seems to me a good option.

Answer 5

I must say that rendering SVG or OpenVG with OpenGL or OpenGL ES is fundamentally a bad idea. There is evidence that the implementation of OpenVG is so slow and largely abandoned. The process of tessellating paths (the basics of all SVG / OpenVG rendering) to triangle lists, as OpenGL requires, is fundamentally slow and inefficient. This basically requires the insertion of a sort / search algorithm into the 3D rendering pipeline, which reduces performance. There is also the problem that a dynamic memory allocation scheme is required since the size of the data set is unknown, since SVG does not limit the complexity of the path geometry. Very bad design.

SVG and OpenVG were created by developers who had little understanding of how modern 3D graphics hardware works (triangles lists). They were created to be an open source alternative to Adobe Flash, which also has the same erroneous architecture that made Flash offended by the industry for unpredictable performance.

My advice is to rethink your design and use OpenGL triangle lists. You may need to write more code, but your application will work about a thousand times better, and you can debug your code more easily than anyone else.

Answer 6

You can take a look at AmanithVG , they seem to have implemented a good path -> triangle. I have tried the iOS GL tiger example, and it seems that triangulation is not a real bottleneck.