Rendern von SVG mit OpenGL (und OpenGL ES)

Vom 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);
}

Also es wird ein VBO. Also ich würde vorschlagen, machen Sie Ihre eigenen SVG-parser /verwenden Sie ein pre-made-man, und leiten die Anrufe an ShivaVG.

Haben Sie immer noch das problem, dass ShivaVG ist in C (und nicht in Java) und erzeugt einen opengl-Kontext (und nicht opengles, wenn ich Lesen Sie den code korrekt). Also selbst wenn Sie es kompilieren mit Android NDK, müssen Sie den code ändern ( zum Beispiel, ich habe ein paar gesehen glVertex3f herum, aber Sie scheinen nicht zu viel gebraucht... das beste hoffen). Die andere option, natürlich, ist es um die Portierung des Codes von C nach Java. Vielleicht nicht so schmerzhaft wie man sich vorstellen kann.

Glück !

InformationsquelleAutor der Antwort Calvin1602

Meine Antwort wird über die Anzeige von Vektor-Grafiken mit OpenGL im Allgemeinen, weil alle Lösungen für dieses problem kann die Unterstützung eher trivial SVG-insbesondere, aber keine Unterstützung animierte SVGs (SMIL). Da gab es nichts, sagte über animation, ich nehme an, die Frage impliziert statische SVGs nur.

Zuerst, ich würde nicht die Mühe mit etwas, OpenVG, auch nicht mit MonkVG, was wahrscheinlich die meisten modernen, wenn auch unvollständigen Umsetzung. Die OpenVG-Ausschuss gefaltet hat, im Jahr 2011, und die meisten, wenn nicht alle Implementierungen sind abandonware oder am besten legacy-software.

Seit 2011, der Stand der Technik ist Mark Kilgard ' s baby, NV_path_renderingdie derzeit nur ein Hersteller (Nvidia) Erweiterung, wie Sie schon erraten haben vielleicht schon von seinem Namen. Es gibt eine Menge von Material, dass:

• https://developer.nvidia.com/nv-path-rendering Nvidia hub, aber etwas material auf die landing page ist nicht die meisten up-to-date
• http://developer.download.nvidia.com/devzone/devcenter/gamegraphics/files/opengl/gpupathrender.pdf Siggraph 2012 Papier
• http://on-demand.gputechconf.com/gtc/2014/presentations/S4810-accelerating-vector-graphics-mobile-web.pdf GTC 2014 Präsentation
• http://www.opengl.org/registry/specs/NV/path_rendering.txt offiziellen extension-doc

Natürlich können Sie laden SVGs und solche https://www.youtube.com/watch?v=bCrohG6PJQE. Sie unterstützen auch die PostScript-syntax für Pfade. Sie können auch mischen Pfad rendering mit anderen OpenGL (3D) Zeug, als führten Sie unter:

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

NV_path_rendering wird jetzt von Google-Bibliothek Skia hinter den kulissen, wenn verfügbar. (Nvidia trug Sie den code in spät 2013 und 2014.) Einer der Kairo-Entwickler (wer ist ein Mitarbeiter von Intel) scheint es zu http://lists.cairographics.org/archives/cairo/2013-March/024134.htmlobwohl ich [noch] nicht bewusst keine konkreten Bemühungen für Kairo zu verwenden NV_path_rendering.

NV_path_rendering hat einige kleinere Abhängigkeiten auf die fixed pipeline, so kann es ein bisschen lästig für die Verwendung in OpenGL ES. Dieses Problem dokumentiert in der offiziellen extension-doc weiter oben verlinkt. Für einen workaround siehe zum Beispiel, was Skia/Chrom getan hat: https://code.google.com/p/chromium/issues/detail?id=344330

Einen Emporkömmling, der mit noch weniger (oder gar keine) Unterstützung durch den Anbieter oder akademischen glitz NanoVGdie derzeit entwickelt und gepflegt. (https://github.com/memononen/nanovg) Gegeben, die Anzahl der 2D-Bibliotheken über OpenGL, die sind gekommen und gegangen im Laufe der Zeit, Sie nehmen eine große Wette mit so etwas nicht unterstützt, die von einem großen Hersteller, meiner bescheidenen Meinung nach.

InformationsquelleAutor der Antwort Fizz

Es muss gesagt werden, dass das Rendern von SVG-oder OpenVG mit OpenGL oder OpenGL ES ist grundsätzlich eine schlechte Idee. Es gibt Gründe, die OpenVG-Implementierungen sind alle so langsam und weitgehend aufgegeben. Der Prozess der parkettierung Pfade (die Grundlage aller SVG/OpenVG rendering) in Dreieck-Listen, wie Sie durch OpenGL ist grundsätzlich langsam und ineffizient. Es ist im Grunde erfordert das einfügen eines sort/search-Algorithmus in der 3D-rendering-pipeline, die Krüppel Leistung. Es gibt auch das problem, dass eine dynamische Zuweisung von Speicher Regelung ist erforderlich, weil die Größe der Daten ist unbekannt, da SVG stellen keine Grenzen für die Komplexität des Pfad-geometrie. Ein wirklich schlechtes design.

SVG und OpenVG wurden erstellt von Entwicklern, die hatten wenig Verständnis dafür, wie moderne 3D-Grafik-hardware, die Motoren tatsächlich arbeiten (Dreiecks-Listen). Sie wurden geschaffen, um eine offene alternative zu Adobe Flash, die auch die gleiche fehlerhafte Architektur gemacht hat, dass Flash geschmäht in der Branche für nicht vorhersehbare performance.

Mein Tipp: überdenken Sie Ihre design-und OpenGL-Dreieck-Listen direkt. Möglicherweise haben Sie mehr code schreiben, aber Ihre app ausführen, etwa tausend mal besser und Sie können leichter Debuggen von code, als jemand elses.

InformationsquelleAutor der Antwort ClayMontgomery