---

本文將為大家闡明IOS 創立OpenGL 環境的考慮的相關引見，詳細實例請看下文

關於如何從頭開端創立環境，可以參考大神的博文OpenGL ES 3.0 數據可視化 0：Hello world,本文只是補充一些我在理論中的一些考慮。

CAEAGLLayer

If you plan to use OpenGL for your rendering, use this class as the backing layer for your views by returning it from your view’s layerClass class method. The returned CAEAGLLayer object is a wrapper for a Core Animation surface that is fully compatible with OpenGL ES function calls.

CAEAGLLayer

依據官方文檔的闡明，這個layer用於OpenGL與Core Animation庫之間的聯絡。這個layer的內容來自於一個 renderbuffer，而他自己所做的次要任務就是為renderbuffer分配內存，在用戶繪制完成後講renderbuffer送給Core Animation.運用的辦法大家都知道，就是override view的layerClass靜態辦法，前往這個東西。

創立Framebuffer和Renderbuffer

創立這倆buffer絕對容易了解，這裡沒有GLKViewController來替我們創立所需的OpenGL環境所以我們需求自己創立用與繪制的buffer，沒有這倆buffer，相當於沒有畫板。我們用OpenGL做Render to texture這樣的事情的時分也需求自己創立framebuffer object，但是那時分往往不必renderbuffer，而運用texture。這兩者的區別是這樣的，在過來那些美妙光陰裡紋理是framebuffer附件的獨一可用的類型，後來引進的renderbuffer object，那麼相比擬texture，Renderbuffer的優點是，以OpenGL原生渲染格式貯存它的數據，因而在離屏渲染的時分，這些數據就相當於被優化過的了。

渲染緩沖對象將一切渲染數據直接貯存到它們的緩沖裡，而不會停止針對特定紋理格式的任何轉換，這樣它們就成了一種疾速可寫的存儲介質了。但是，渲染緩沖對象通常是只寫的，不能修正它們（好像獲取紋理，不能寫入紋理一樣）。可以用glReadPixels函數去讀取，函數前往一個以後綁定的幀緩沖的特定像素區域，而不是直接前往附件自身。

由於它們的數據曾經是原生格式了，在寫入或把它們的數據復雜地到其他緩沖的時分十分快。當運用渲染緩沖對象時，像切換緩沖這種操作變得異常高速。我們在每個渲染迭代末尾運用的那個glfwSwapBuffers函數，異樣以渲染緩沖對象完成：我們復雜地寫入到一個渲染緩沖圖像，最後交流到另一個裡。渲染緩沖對象關於這種操作來說很完滿。 Renderbuffer

有些切題，回到IOS這邊，示例代碼如下

GLuint colorRenderbuffer;
glGenRenderbuffers(1, &colorRenderbuffer);
glBindRenderbuffer(GL_RENDERBUFFER, colorRenderbuffer);
[myContext renderbufferStorage:GL_RENDERBUFFER fromDrawable:myEAGLLayer];
glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_RENDERBUFFER, colorRenderbuffer);

該闡明的中央大神的博文曾經闡明此處不再贅述，但是需求留心的事情是，由於renderbuffer的尺寸是從EAGLLayer中失掉，假如EGLLayer的尺寸不正確，會招致最終的圖像大小不如預期。在apple的 Supporting High-Resolution Screens In Views 這篇文章提到，在高分辨率的設備上渲染OpenGL ES， 假如不做設置，那麼呈現的圖像會變得blockly，應該是說是塊狀的，就是不太明晰，其建議就是運用較大的scale值。可以這樣設置:

eaglLayer.contentsScale = [UIScreen mainScreen].scale;

記住，假如將eagl layer 的scale值設置變大了，那麼在glviewport() 的時分要運用相應的成倍數的尺寸。

我自己理論了一下，iPhone7 Plus 上，[UIScreen mainScreen].bounds 失掉的尺寸為414x736，設置glviewport為這個尺寸，出來的圖像正常。然後如下修正：

eaglLayer.contentsScale = [UIScreen mainScreen].scale;

glViewport(0, 0, (GLsizei) (size.width * scale),
 (GLsizei) (size.height * scale));

即同時修正layer和viewport，失掉的後果粗看起來和原來的差異不大，但是細心檢查細節邊緣，前者的鋸齒會更分明，後者分辨率更好。所以總的思緒就是layer的scale和viewport要堅持同步，兩個都不改也可，兩個都改也可。假如只修正了viewport的值，將其增大了，那就相當於視口變大了，底下的renderbuffer還是那麼小，renderbuffer只能留下窗口的一個角落的圖像。看起來就是，圖像放的很大，然後只能看見角落外面的局部，一看就知道有問題。我們可以用上面的辦法來確認renderbuffer的大小對不對。

// Get the renderbuffer size.
GLint width;
GLint height;
glGetRenderbufferParameterivOES(GL_RENDERBUFFER_OES, GL_RENDERBUFFER_WIDTH_OES, &width);
glGetRenderbufferParameterivOES(GL_RENDERBUFFER_OES, GL_RENDERBUFFER_HEIGHT_OES, &height);

好了，就說這麼多吧。再見！ 

以上就是這篇文章的全部內容了，希望大家可以喜歡。

【iOS 創立OpenGL 環境的考慮】的相關資料介紹到這裡，希望對您有所幫助！ 提示：不會對讀者因本文所帶來的任何損失負責。如果您支持就請把本站添加至收藏夾哦！