6

When a GLKView is resized, there are some behind-the-scenes operations that take place on the buffers and context of that GLKView. During the time it takes to perform these behind-the-scenes operations, drawing to the GLKView does not produce correct results.

In my scenario, I have a GLKView that has setNeedsDisplay enabled, so that anytime I need to update it's contents on screen, I just call -setNeedsDisplay on that GLKView. I'm using GLKView to draw images, so if I need to draw an image with a different size, I need to also change the size of the GLKView.

The problem: When I change the size of the GLKView and call setNeedsDisplay on that view, the result on screen is not correct. This is because the GLKView is not done finishing the behind-the-scenes operations invoked by the new size change before it tries to draw the new image.

I found a work-around to this by calling: performSelector:@selector(setNeedsDisplay) withObject:nil afterDelay:0 instead of just setNeedsDisplay on the GLKView. This basically forces the main thread to wait for all the behind-the-scenes openGL operations to be completed before calling setNeedsDisplay. Although this works ok, I am wondering if there is a better solution. For example, is there an openGL call to make the thread wait for all openGL operations to be completed before continuing?

spybart
  • 2,583
  • 3
  • 22
  • 33

1 Answers1

9

The solution was to reset the CIContext object after the GLKView has been resized.

Nimantha
  • 6,405
  • 6
  • 28
  • 69
spybart
  • 2,583
  • 3
  • 22
  • 33
  • How did you reset it? Recreating it from scratch? Or is there a specific method to call. – flainez Jan 22 '17 at 16:34
  • 1
    In my case, after the resize I was setting my `CIContext` object like so: `ci_context = [CIContext contextWithEAGLContext:glkView.context]` and then calling `[glkView display]`. Note that this was a long time ago and I didn't pursue learning about this, so don't assume it's the right approach. – spybart Jan 23 '17 at 02:39