Ability to choose the type of context that you are getting

[Mechscientist]

This might be a documentation issue, but I don't see a way to choose whether you are getting a legacy, compatibility or core context. The examples seem to point to a legacy or compatibility context.

There instances where you want to have the ability to choose, like for testing code compatibility. You may also want to specifically get an OpenGL ES context to validate your code will run on systems that only support OpenGL ES.

(The source code would also be nice as well so one could see what it's doing ;-)

Thanks!

[culler]

The source code for the Tk extension, which is named TkGL, is available on github at:

https://github.com/3-manifolds/TkGL

In tkinter-gl, the Python class GLCanvas has an attribute named profile which determines which type of context should be requested. A subclass can override that attribute. This is done in the examples.

[Mechscientist]

Thanks and sorry I missed that. It looks like there currently is no support for OpenGL ES contexts? Is that something you plan on supporting if you support ARM?
Thanks in advance!

[culler]

I am not sure what would be involved in supporting OpenGL ES contexts, or what that has to do with supporting ARM. Any information about that would be helpful!

…

On Wed, Apr 16, 2025 at 1:57 PM Mechscientist ***@***.***> wrote: Thanks and sorry I missed that. It looks like there currently is no support for OpenGL ES contexts? Is that something you plan on supporting if you support ARM? Thanks in advance! — Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJ6CP5LYTK5HH2GT22OELL2Z2RZLAVCNFSM6AAAAAB3IT7V3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMJQGQ3DSMJXHE> . You are receiving this because you commented.Message ID: ***@***.***> *Mechscientist* left a comment (3-manifolds/tkinter_gl#4) <#4 (comment)> Thanks and sorry I missed that. It looks like there currently is no support for OpenGL ES contexts? Is that something you plan on supporting if you support ARM? Thanks in advance! — Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJ6CP5LYTK5HH2GT22OELL2Z2RZLAVCNFSM6AAAAAB3IT7V3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMJQGQ3DSMJXHE> . You are receiving this because you commented.Message ID: ***@***.***>

[Mechscientist]

ARM processors are used on RPi and other embedded systems that only support OpenGL ES - I was just wondering if you were going that direction as I know that Windows can run on ARM as well. I'd have to look at your code a more deeply to fully respond to how to do it, but In taking a quick look, I think your windows code, is using WGL to get a context. There's an extension that lets you get ES and ES 2.0 here. It's a little tricky on Windows as not all drivers support ES and you have to use ANGLE as a shim to a supported graphics language for those that don't. I haven't directly used X11 to get a context for a while as GLFW seems to handle this well, and getting an ES context from that is pretty easy. Sorry, not sure how to to do it on Mac, and it's been a while since I did it on ARM, but I think you can use EGL or just use GLFW. I think, in fact you might be able to use GLFW for all of your systems and reduce your code burden, but I've only cursively looked at it so I might be missing something.

[culler]

TkGL is an alternative to GLFW, using Tk to provide the GL renderiing surface. So using GLFW does not make any sense. Apple has deprecated OpenGL, but they still provide it for ARM even though the deprecation happened before Apple started producing the Apple Silicon chips. There will never be anything new than 4.1 on Apple, however. Apparently Apple does provide ES, according to https://developer.apple.com/documentation/opengles?language=objc but I am having a hard time seeing why that would be useful when a full GL implementation is available at no extra cost.

I do have some Arm-based SOC Ubuntu systems. I will do some testing on those to see what works on them.

[Mechscientist]

Yes, you are right, about GLFW. I was thinking more about context creation rather than window creation. I've been using GLFW to create an offscreen window and then draw into FBO's.

The reason for supporting ES on non-ARM systems would be to not have to have 2 different sets of graphics code if you had an application that was meant to run on both types of systems.
Thanks for responding to my questions!