android opengl教學 - 使用OpenGL(和OpenGL ES)渲染SVG




3 Answers

來自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);
}

所以它確實使用VBO。 因此,我建議您製作自己的SVG解析器/使用預製的解析器,並將調用轉發給ShivaVG。

你仍然有ShivaVG在C(而不是Java)中的問題,並創建一個opengl上下文(如果我正確讀取代碼,則不是opengle)。 所以,即使你使用Android的NDK編譯它,你也必須修改代碼(例如,我已經看到了一些glVertex3f,但它們似乎並不太需要......希望最好)。 當然,另一個選擇是將代碼從C移植到Java。 也許沒有你想像的那麼痛苦。

祝你好運 !

eglcreatewindowsurface graphics

我目前正在研究使用OpenGL和OpenGL ES從SVG文件渲染矢量圖形的可能性。 我打算以Windows和Android為目標。 我理想的解決方案是擁有一個最小的C庫,從給定的SVG文件生成多邊形三角剖分。 然後,這將生成標準的OpenGL或OpenGL ES調用,並在重繪時使用顯示列表或vbo進行優化。 我只需繪製一個顯示列表,在翻譯和旋轉後繪製矢量圖像,允許我將其與其他OpenGL調用混合。

到目前為止,我看到建議首先使用QT或開羅。 - 這不是一個選項,因為我希望在沒有膨脹庫的情況下管理我自己的OpenGL上下文(在我想要實現的內容中)。 這也不適合Android。

第二個選項是使用渲染到紋理的庫。 雖然靜態矢量圖形可能沒問題,但對於頻繁出現縮放和旋轉的遊戲來說,它不是一個有效或可行的選擇。

第三,有可能使用OpenVG。 OpenVG規範(ShivaVG等)有一些開源實現,但是我還沒有找到一個能夠在運行時從給定的SVG文件生成適當的OpenVG調用的庫,我無法看到如何優化它我們可能希望使用顯示列表或vbo。

這三種方法都有局限性。 我認為最有希望的選擇是在沒有其他解決方案的情況下使用OpenVG實現。 所以我的問題是,是否有任何圖書館可以做我想要的,或接近我想要的? 如果沒有,有什麼理由不是嗎? 嘗試從頭開始這樣做會更好嗎?




我的答案是關於通常使用OpenGL顯示矢量圖形,因為這個問題的所有解決方案都可以支持相當簡單的SVG,儘管沒有一個支持動畫SVG(SMIL)。 由於沒有關於動畫的說法,我認為這個問題僅暗示靜態SVG。

首先,我不會打擾任何OpenVG,甚至不使用MonkVG,這可能是最現代的,雖然不完整的實現。 OpenVG委員會已於2011年完成,大多數(如果不是全部)實施都是棄用軟件或最好的遺留軟件。

自2011年以來,最先進的是Mark Kilgard的寶貝NV_path_rendering ,它目前只是供應商(Nvidia)的擴展,因為您可能已經從其名稱中猜到了。 有很多材料:

您當然可以加載SVG和https://www.youtube.com/watch?v=bCrohG6PJQE 。 它們還支持路徑的PostScript語法。 您還可以將路徑渲染與其他OpenGL(3D)內容混合使用,如下所示:

NV_path_rendering現在由Google的Skia庫在幕後使用。 (Nvidia在2013年末和2014年提供了代碼。)其中一位開羅開發者(也是英特爾員工)似乎也喜歡它http://lists.cairographics.org/archives/cairo/2013-March/024134.html ,雖然我還沒有意識到cairo使用NV_path_rendering的任何具體努力。

NV_path_rendering對固定管道有一些小的依賴性,因此在OpenGL ES中使用它會有點麻煩。 此問題記錄在上面鏈接的官方擴展文檔中。 有關解決方法,請參閱Skia / Chromium所做的工作: https://code.google.com/p/chromium/issues/detail?id=344330https://code.google.com/p/chromium/issues/detail?id=344330 ?id https://code.google.com/p/chromium/issues/detail?id=344330

NanoVG是目前開發和維護的一個新興企業,其供應商支持或學術上的支持甚至更少(或者說完全沒有)。 ( https://github.com/memononen/nanovg )鑑於OpenGL上的2D庫的數量隨著時間的推移而變得越來越多,我愚蠢地認為,使用不受主要供應商支持的東西進行大賭注。




需要說的是,使用OpenGL或OpenGL ES渲染SVG或OpenVG基本上是一個壞主意。 OpenVG實施的原因很慢並且在很大程度上被放棄了。 根據OpenGL的要求將路徑(所有SVG / OpenVG渲染的基礎)細分為三角形列表的過程基本上是緩慢且低效的。 它基本上需要在3D渲染管道中插入排序/搜索算法,這會削弱性能。 還存在需要動態存儲器分配方案的問題,因為數據集的大小是未知的,因為SVG對路徑幾何的複雜性沒有限制。 一個非常差的設計。

SVG和OpenVG是由對現代3D圖形硬件引擎實際工作原理(三角形列表)知之甚少的開發人員創建的。 它們被創建為Adobe Flash的開放替代品,Adobe Flash也具有相同的有缺陷的體系結構,這使得Flash在行業中因不可預測的性能而受到譴責。

我的建議是重新考慮您的設計並直接使用OpenGL三角形列表。 您可能需要編寫更多代碼,但您的應用程序的性能會提高一千倍以上,並且您可以比其他人更輕鬆地調試代碼。




Related

android opengl opengl-es svg vector-graphics