#3998 breaks GL_CLIP_ORIGIN on OpenGL contexts < 4.5 #4170

New issue

Closed

opened 2021-05-24 20:43:14 +00:00 by u3shit · 5 comments

u3shit commented

2021-05-24 20:43:14 +00:00

(Migrated from github.com)

I just updated to ImGui 1.83 from 1.79, and my gui is upside down again :(

Since #3998 GL_CLIP_ORIGIN is only checked for opengl contexts >= 4.5, but my application actually request 3.3 context and uses the GL_ARB_clip_control extension, which defines the same function and enum values as OpenGL 4.5. (And for example, the nvidia driver gives me a 3.3 core context, where the gui is now upside down and buggy, but the intel driver gives me a 4.5 core context, and everything is fine...)

Unfortunately the opengl backend doesn't parse the list of extensions, so it'd either have to do that, or use the info from the loader (most loaders expose this info, but in a different way). I'm not sure how widespread this functionality in the wild, but seeing how much trouble it causes, I would be even okay with a solution where the backend doesn't try to figure this out on its own, and instead ImGui_ImplOpenGL3_RenderDrawData receives an extra bool parameter (basically the current current_clip_origin variable, default to true so normal GL apps continue to work). Not sure what is the best solution.

Version/Branch of Dear ImGui:

Version: 1.83
Branch: master

Back-end/Renderer/Compiler/OS

Back-ends: imgui_impl_opengl3.cpp + imgui_impl_glfw.cpp
Operating System: Linux

I just updated to ImGui 1.83 from 1.79, and my gui is upside down again :( Since #3998 `GL_CLIP_ORIGIN` is only checked for opengl contexts >= 4.5, but my application actually request 3.3 context and uses the `GL_ARB_clip_control` extension, which defines the same function and enum values as OpenGL 4.5. (And for example, the nvidia driver gives me a 3.3 core context, where the gui is now upside down and buggy, but the intel driver gives me a 4.5 core context, and everything is fine...) Unfortunately the opengl backend doesn't parse the list of extensions, so it'd either have to do that, or use the info from the loader (most loaders expose this info, but in a different way). I'm not sure how widespread this functionality in the wild, but seeing how much trouble it causes, I would be even okay with a solution where the backend doesn't try to figure this out on its own, and instead `ImGui_ImplOpenGL3_RenderDrawData` receives an extra bool parameter (basically the current `current_clip_origin` variable, default to true so normal GL apps continue to work). Not sure what is the best solution. **Version/Branch of Dear ImGui:** Version: 1.83 Branch: master **Back-end/Renderer/Compiler/OS** Back-ends: imgui_impl_opengl3.cpp + imgui_impl_glfw.cpp Operating System: Linux

ocornut commented

2021-05-24 20:53:04 +00:00

(Migrated from github.com)

Hello,
Thanks for opening this.
I guess we should work out a way to check for GL_ARB_clip_control in the backend, that would be simpler and more correct.

Hello, Thanks for opening this. I guess we should work out a way to check for `GL_ARB_clip_control` in the backend, that would be simpler and more correct.

ocornut commented

2021-05-24 20:54:30 +00:00

(Migrated from github.com)

Could you run code of that sort:
https://www.geeks3d.com/20100722/tips-how-to-get-the-list-of-the-opengl-extensions-with-a-core-profile/
With both drivers, and confirm that GL_ARB_clip_control is listed in both cases?

Could you run code of that sort: https://www.geeks3d.com/20100722/tips-how-to-get-the-list-of-the-opengl-extensions-with-a-core-profile/ With both drivers, and confirm that `GL_ARB_clip_control` is listed in both cases?

u3shit commented

2021-05-24 21:18:34 +00:00

(Migrated from github.com)

Yes, I checked, and I have the GL_ARB_clip_control extension listed both with the nvidia and intel driver (and even with osmesa, but that also creates a 4.5 context).

Yes, I checked, and I have the `GL_ARB_clip_control` extension listed both with the nvidia and intel driver (and even with osmesa, but that also creates a 4.5 context).

ocornut commented

2021-05-24 21:49:48 +00:00

(Migrated from github.com)

Pushed a fix for it.
GL being GL I expect one of those new call to fail on some obscure setup, and we'll also fix what once detected.

Pushed a fix for it. GL being GL I expect one of those new call to fail on some obscure setup, and we'll also fix what once detected.

u3shit commented

2021-05-24 22:42:30 +00:00

(Migrated from github.com)

Thanks, it looks like it's working with both cards I can test with.
Now figure out what to do with my old column api based property editor...

Thanks, it looks like it's working with both cards I can test with. Now figure out what to do with my old column api based property editor...