-
Notifications
You must be signed in to change notification settings - Fork 10
[Wrapper] error handling #15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I don't think this is a good idea. Unless we can somehow make it easy to disable this. We cannot make assumptions about driver behaviour or perf impact of I would recommend using an error message callback with This method avoids the need to sprinkle expensive and code-obfuscating glGetError() calls around your application to catch and localize the causes of OpenGL errors (and the need to conditionally compile them into debug builds to avoid the performance hit in optimized builds). The feature can even ensure that message callback functions are invoked on the same thread and within the very same call stack as the GL call that triggered the GL error (or performance warning). I think using an error message callback alongside a graphics debugger serve the user better than employing error sets here. Perhaps we could provide opt-in "default" message callbacks though. |
I agree with @hazeycode here. To start with, the impact of |
I'm ignoring Apple here on purpose because thats the worst platform to run opengl on anyway. If you can, (there is no excuse not to anyway) target the latest version of OpenGL and use But again, its just a stupid wrapper, dont overcomplicate it as mentioned here zig-gamedev/zig-gamedev#674 |
Most OpenGL functions can return errors, but they have to be handled manually.
https://www.khronos.org/opengl/wiki/OpenGL_Error
Should the wrapper handle this?
I think it could be cool to have the functions return the error directly if it happens.
My idea is to have a wrapper around each binding call that would do 1) empty the error queue 2) execute the opengl function 3) check if there is a new error and, if so return it.
This is quite the major change in the wrapper, so I want to know what you think about it before doing so.
The text was updated successfully, but these errors were encountered: