Running Xcode OpenGL ES diagnostics in a very simple application that switches to the second framebuffer and vice versa (using glClear and glInvalidateFramebuffer accordingly) displays warnings about logical buffer storage when switching to the second framebuffer:
- (void)glkView:(GLKView *)view drawInRect:(CGRect)rect { // At this point, GLKView framebuffer is bound // Clear (to avoid logical buffer load) glClear(GL_COLOR_BUFFER_BIT); // Invalidate (to avoid logical buffer store) glInvalidateFramebuffer(GL_FRAMEBUFFER, 1, (GLenum[]){ GL_COLOR_ATTACHMENT0 }); // Switch to our own framebuffer, and attach a texture as the color attachment // At this point, Xcode OpenGL ES tool warns: // "For best performance keep logical buffer store operations to a minimum." glBindFramebuffer(GL_FRAMEBUFFER, _framebuffer); glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, _texture, 0); // Clear (to avoid logical buffer load) glClear(GL_COLOR_BUFFER_BIT); // Invalidate (to avoid logical buffer store) glInvalidateFramebuffer(GL_FRAMEBUFFER, 1, (GLenum[]){ GL_COLOR_ATTACHMENT0 }); // Might want to switch back to GLKView drawable here, and do more rendering }
Anyone have any ideas on why invalidation is not held back? Note that in this example, GLKView only has a color buffer binding:
view.drawableColorFormat = GLKViewDrawableColorFormatRGBA8888; view.drawableStencilFormat = GLKViewDrawableStencilFormatNone; view.drawableDepthFormat = GLKViewDrawableDepthFormatNone; view.drawableMultisample = GLKViewDrawableMultisampleNone;
A test application demonstrates this at https://dl.dropboxusercontent.com/u/6956432/test.zip
Hooray!
source share