Apple Deprecating OpenGL...will that impact Mac version of KiCad?

https://developer.apple.com/macos/whats-new/#deprecationofopenglandopencl

Saw this announced at WWDC the other day and immediately thought about KiCad and the positive effects that the OpenGL layout tool has had on the platform. Any ideas if this will impact the KiCad build…or is the OpenGL dependencies installed alongside KiCad?

I’m an occasional mac user and mostly use Parallels + Ubuntu 16 to get a consistent KiCad experience on this computer. I had heard the nightly builds were really integrating well with Mac OS though and thought it would be a positive step forward for brining more into the fold. Hopefully these announcements don’t change that?

1 Like

https://lists.launchpad.net/kicad-developers/msg36069.html

1 Like

https://forum.freecadweb.org/viewtopic.php?f=8&t=29124
https://forum.freecadweb.org/viewtopic.php?f=8&t=29124#p237502

…but as they said, Vulkan isn’t updated OpenGL. I’m not an expert, but I have read something about it, and OpenGL is higher level, Vulkan lower level. Moving to Vulkan would mean more work and would benefit only fast games etc. where rendering speed is critical. Vulkan is new and moving to it would mean leaving older hardware. Supporting older hardware is kind of a “selling point” for KiCad.

But it’s probable that some solution will emerge.

While they have announced this deprecation with this MacOS release, I’m betting it will be a while before OpenGL support is removed. More likely it will just stop getting updates. I don’t think this is an immediate crisis for KiCad, but we will probably eventually need to support another graphics acceleration system on MacOS. The good news is that a lot of the hard work is done already in getting us ready for an issue like this. The new GAL system for KiCad will make it a lot less work to add support for other graphics APIs in the future. I don’t think any of us can say now what the right path is, whether to implement a Metal backend directly or use something like MoltenVK, but I think this will become more clear as time goes on and some of the alternatives to OpenGL become more mature and are used by other open source projects.

3 Likes

Please do not let this be another gtk2 nonsense. (Where you have to write into the release notes of one release that this is a known problem but do not solve it for the next release.)
At least start now with the planning for what you supply for the time after opengl. (Remember it might be quite a while till v6 is released. Even if at that point in time opengl still exists for mac, are you sure you can wait till v7?)

Like I said, the general plan would be to write a new backend for the GAL that connects to a different graphics API. I think it’s too early to tell which graphics API will be the best for us to use for MacOS support (we could write something for Metal, but then it would only work on MacOS, or we could write something for Vulkan, but then we have other layers of libraries that we need to rely on).

Writing a GAL backend for Metal or Vulkan is something that anyone could do at any time, but speaking for myself, I will be focusing on bringing modernization and the GAL framework to Eeschema, since only after we have all of KiCad running on GAL can we have a way to support all platforms the same way even with different graphics APIs.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.