ofFbo not compatible with presentViewController on iOS

[christophe311]

tested on 0.9.3 and master, based on example iosNativeExample :

1. use ofFbo to draw the image in ImageApp
2. ofFbo fbo; in ImageApp.h
3. fbo.allocate(image.getWidth(),image.getHeight()); at the end of ImageApp::setup()
4. fbo.begin(); image.draw(0, 0); fbo.end(); at the end of ImageApp::update()
5. fbo.draw(x,y,image.getWidth(),image.getHeight()); instead of image.draw(x, y); in ImageApp::draw() http://pastebin.com/raw/xLLcNDPi
6. use presentViewController in MyAppViewController button4Pressed
7. [self.parentViewController presentViewController:viewController animated:YES completion:nil]; http://pastebin.com/raw/W25JXyA3

When tested on iPhone 6 plus ios 9.1 or 9.3.1, and on simulators, pressing on Image button in main screen leads to a gray screen (nothing displayed). When commenting the usage of ofFbo, the image display just fine (as well as all indicators of the test).

The minimal change to reproduce it is to have to call ofFbo::begin() and ofFbo::end() in update to reproduce the problem. The problem can be reproduced with all 4 cases of this example.

If using the regular NavigationViewController pushController in button4Pressed, ofFbo usage works. OpenGL ES1 or ES2 : no impact on bug.

[jvcleave]

Is it failing here with the backingWidth and backingHeight being 0?

https://github.com/openframeworks/openFrameworks/blob/master/addons/ofxiOS/src/gl/ES1Renderer.m#L94

[christophe311]

nope.

In both cases (with or without fbo), no GL error and on simulator iPhone 6 plus : (lldb) p backingHeight (GLint) $0 = 1704 (lldb) p backingWidth (GLint) $1 = 960

[danoli3]

I've seen this before, my solution in the past is to allocate FBO's on the first frame rather than setup as a hack. I believe the GL context isn't available in the present stack to allocate the texture

[christophe311]

by allocating the fbo in the first call to draw, at least it does not break the full display. but the content of the fbo is still not drawn. http://pastebin.com/C7C7Agcs

let me point out again that there is a link (somehow) between the fbo behavior and the api chosen to display the ios view (presentViewController vs pushViewController)

[jvcleave]

The new ImageApp() in this line seems strange

viewController = [[[ImageAppViewController alloc] initWithFrame:[[UIScreen mainScreen] bounds]
                                                                app:new ImageApp()] autorelease];

wouldn't you already have a pointer to ImageApp to use?

[christophe311]

that is the way the iosNativeExample is built (same for CircleApp, TriangleApp, SquareApp in the project). The ImageApp is created when you press on the button. It makes sense. And it works nicely when the viewController is pushed (instead of presented) and when you do not use a fbo. The bad combination is using a fbo AND presenting the viewController : these 2 are apparently not related at all. As far as I can tell, it is the call to glBindFramebuffer(GL_FRAMEBUFFER, currentFramebufferId); line 500 of ofGLRenderer that is the culprit. The currentFramebufferId is indeed the appropriate fbo id, but the fbo does not display its content.

[christophe311]

by tweaking further the iosNativeExample, this time by using the TriangleApp and adding a delay before allocating and using the fbo, you can see that the Triangle app view is updated just fine (with frame rate for example) until the fbo is bound for the first time. After that, the Triangle app view is frosen. There is no GL errors and the update/draw cycle is still happening. calls to ofFbo.begin() and ofFbo.end() are just enough to show this freeze. here is the modified TriangleApp : http://pastebin.com/3CxbZM6T

again, this is happening only if the controller is presented instead of pushed.

[jvcleave]

related #5436