使用OpenGL ES 3.0进行GLKit多重采样

Question

I am in the process of migrating a small iPad application from OpenGL ES 2.0 to OpenGL ES 3.0. In the App, I use a subclass of GLKView to handle all my drawing, though the only GLKit features I use are:

self.context = [[EAGLContext alloc] initWithAPI:kEAGLRenderingAPIOpenGLES3]; // Or 2
self.drawableDepthFormat = GLKViewDrawableDepthFormatNone;
self.drawableColorFormat = GLKViewDrawableColorFormatRGBA8888;
self.drawableMultisample = GLKViewDrawableMultisample4X;
self.drawableStencilFormat = GLKViewDrawableStencilFormatNone;
self.enableSetNeedsDisplay = YES;
// ... gl code following

My -drawRect method looks like this:

glClearColor(1, 1, 1, 1);
glClear(GL_COLOR_BUFFER_BIT);

[_currentProgram use]; // Use program
glUniformMatrix4fv([_currentProgram getUniformLocation:@"modelViewProjectionMatrix"], 1, 0, modelViewProjectionMatrix.m);

// ...
if (isES3) {
    glBindVertexArray(vertexArray);
}
else {
   glBindVertexArrayOES(vertexArray);
}
glDrawArrays(GL_TRIANGLE_STRIP, 0, verticiesLength);

---

I do not yet have a OpenGL ES 3.0-capable device so all of my OpenGL ES 3.0 testing is being done in the iOS Simulator. OpenGL ES 2.0 testing is done on-device and in-simulator.

As expected, in ES2 , the screen is cleared to white immediately on startup ( -drawRect having been called once and no vertices to draw yet). However, when I make the swap to ES3 , the context is successfully created, no gl calls fail, and yet the screen does not clear as it should - it just appears as a black screen. Fishing around for what was going wrong, I decided to remove multi-sampling:

self.drawableMultisample = GLKViewDrawableMultisampleNone;

And it worked! (Albeit without antialiasing.) My question is therefore, are there any known issues with GLKit multi-sampling with OpenGL ES 3.0 in the iOS Simulator (iPad, iPad Retina and iPad Retina (64-Bit))? My laptop has more than enough free memory to cope with the multi-sampling.

Answer 1

OpenGL is a very asynchronous API. For example, if you call glClear , you should not expect the screen to be cleared when the call returns. You can only reliably look at the result of the rendering you produced after you finished rendering the frame, and it is displayed (typically by swapping the buffers when using double buffered rendering).

So what you're observing most likely does not mean anything. Does everything look fine at the end of the frame? If yes, there's no reason to be worried.

The difference is likely caused in the different rendering process if multisampling is enabled. In this case, rendering goes to a higher resolution buffer first, and is only downsampled to the actual framebuffer at the end of the frame.

Answer 2

部署时，从“常规”>“部署信息”菜单中将设备类型选择为iPad，而不是通用设备，即可对其进行修复。