Misbehavior (with fix) on iOS when using FrameBuffer

[b3nk4n]

Misbehavior (with fix) on iOS when using FrameBuffer

[Tom-Ski]

Looked closer into this, and Ok this is nuts! 👁️

I think this was introduced by 0f24d72 as we have changed creation callback from waiting for the first frame, but I'm still super surprised that it hasn't been reported before you.

I guess most of us are not creating framebuffers on create, (usually after some splash screen which doesn't require FBO would be my guess)

Its not apparent in the test bench, since they construct their framebuffers after a first render due to structure of test suite. This has to happen in the create of the Adapater. We need to wait for the very first frame before finding the 'default' render buffer handle it seems as it returns 0 until we get that first frame.

I'd rather not query something on every single interaction with framebuffers, every little helps with not putting gl commands into the buffers. Perhaps we can bring back the first frame logic, even if its for setting the default handle.
Should take a look at #6971 again and see if we can find a better solution for all.

[b3nk4n]

Personally, I'm unblocked by my workaround. However, would be happy to provide a PR for this reported problem. Before doing so, I would however like to get some questions clarified before I would create a PR, to have less back and forth as part of the final PR:

Questions:

1. Is there any strict need to only set the defaultFramebufferHandle only once via defaultFramebufferHandleInitialized, instead of whenever an FBO is created? Are e.g. these OpenGL functions to get the FRAMEBUFFER_BINDING expensive?
2. Would you prefer fixing this in a way that yields iOS specific special handling, as in the current implementation here? Even when the fix (or iOS special handling) also would work fine with other platforms? Or instead better have a single implementation that works for all the same way. Even when there might be a slightly more optimal implementation for specific platforms (e.g. simply assume defaultFramebufferHandle = 0 if platform is not iOS)

Thank you in advance!

[Tom-Ski]

Tested this on device, and it does not reproduce. Are you testing on sim here?

[b3nk4n]

Tested this on device, and it does not reproduce. Are you testing on sim here?

I tested this on both a simulator with iOS 17.0 on an iPhone 15 with the following simulator version:

Version 15.0.1 (1015.2)
SimulatorKit 935.1
CoreSimulator 932.2

And using iOS 17.1.1 on my physical iPhone 13 device.

Thx @Tom-Ski for all the details above 👍
If I understand correctly, if I would skip creating the FBO in just the very first frame, then things would work correctly (Edit: and I can confirm that this is working that way when I create the FBO lazily in the second frame).

Sounds more complicated that I thought. And would therefore better leave that to you, as you seem to have a lot of context around this already. But let me know in case there is anything I can help with.
Thx!

[LobbyDivinus]

So this will be fixed? Nice. I also stumbled across this issue when using shadow light which internally uses a framebuffer. Postponing the creation until the first update call works but doesn't feel right.