Add debug messaging during OpenGL init phase for non-debug build

[dkasuga]

Currently, in Filament's optimized builds, error-checking macros like CHECK_GL_ERROR are disabled, likely for performance or code size reasons. However, this poses a problem for developers who use Filament as a pre-built library. They find it difficult to detect initialization errors originating within Filament, even if their own application is a debug build.

This change proposes the addition of functionality to output warning messages when OpenGL errors occur during initialization, even in optimized (non-debug) builds.

FIXES=[333130292]

[pixelflinger]

This will actually terminate the program, so it's more than just a "warning".

I think this is how this should work:

• on debug builds, we always call assertGLError
• on release builds, by default we do nothing unless FILAMENT_ENABLE_INIT_GL_WARNINGS_FOR_OPTIMIZED_BUILD is set, in which case we call checkGLError (i.e. we don't crash in release builds, just log).

[dkasuga]

Thanks for your review. I now agree for using checkGLError for the "warning" purpose.

Following your suggestion I updated the macro definition and the cmake option default value (from ON to OFF), but I now wonder if assertGLError should be really added for debug builds by the new macro. If we limit assertions only to the debug build, the existing CHECK_GL_ERROR insertions should be enough, and there might be no need to add new assertions (to the parts where I inserted the new macro). WDYT?

[z3moon]

I see that the new CHECK_GL_INIT_ERROR_FOR_OPTIMIZED_BUILD macro has a specific purpose and isn't intended as a direct replacement for CHECK_GL_ERROR.

I guess mathias meant to keep our current idiom, assert for debug, assuming this new macro can be a replacement for CHECK_GL_ERROR. However, if your intention is for this new macro to be an additional check used alongside CHECK_GL_ERROR, meaning users might need to call both, that could be unintuitive without detailed comments. So comprehensive comments detailing the specific use case may be needed.

Either way, I would consider making the new macro sound more generic, renaming it something like CHECK_GL_ERROR_FOR_RELEASE, indicating this macro is to govern the behavior in release mode.