OpenGL.framework

[bugaevc]

Right now, we are using Cocotron's implementation of OpenGL.framework (aka Core OpenGL aka CGL), which is (Win32- and) X11-specific. It is implemented as a wrapper around GLX, and AppKit (X11Window) uses both CGL and GLX calls. Furthermore, CGL itself knows about X11Windows and links to AppKit, creating a circular dependency between the two.

While this is good enough for now, it's not very future-proof, which is why we would like to implement our own version of CGL.

• It should implement the complete CGL API, as documented here
• It should wrap host's EGL, because we want it to work on X11, Wayland, and maybe even on Android
• It should not depend on AppKit
  • Linking to OpenGL.framework should not bring in AppKit
  • It should be possible to do offscreen rendering without any X11/Wayland connection whatsoever
• It should reexport all the gl* symbols from the native libGL
• AppKit should only use CGL* and gl* APIs
  • And only link to OpenGL.framework, not native libGL/GLX
• CGL should provide private API extensions to let AppKit register its windowing system connection and create CGL contexts for windows/surfaces
  • Think eglGetDisplay and eglCreateWindowSurface
  • Except we would also need to e.g. use eglGetConfigAttrib() to choose the visual for X11 and pass it back to AppKit
• Should AppKit or CGL call wl_egl_* stuff?

[woachk]

$ swift test.swift

2019-05-22 13:42:16.591 swift[194:3e8] FreeType font face is not scalable
MESA-LOADER: failed to open swrast (search paths /usr/lib/x86_64-linux-gnu/dri:$${ORIGIN}/dri:/usr/lib/dri)
libGL error: failed to load driver: swrast
2019-05-22 13:42:16.774 swift[194:3e8] CGLCreateContext failed at /home/someone/darling/src/external/cocotron/AppKit/X11.backend/X11Window.m 430 with error 10004

Isn't totally functional too..

[bugaevc]

Yes, GUI apps are still officially unsupported. They unofficially work, but you need some special setup for now; this is not an issue of OpenGL.framework, it's a generic limitation of how we do chrooting, we're going to solve this at that level.

[woachk]

@bugaevc what's the setup needed to test? copying over the _dri.so(s) doesn't seem to be enough on its own.

[bugaevc]

Symlink over enough of /usr/lib/dri (or wherever they are), copy over / symlink the GLVND config (/usr/share/glvnd), maybe symlink or bind-mount /sys, maybe also /usr/share/drirc//etc/drirc. If that's not enough, strace it and see what else it needs.

[bugaevc]

If you get it to work, you'll also need some workaround for #368; the easiest is to patch NSApplication to make all the run loop mode names the same.

[CuriousTommy]

Will this work also be upstreamed to Cocotron, or would it be too Darling specific?

[bugaevc]

The original Cocotron is abandoned since 2015 or so, and our fork of it has a lot of fixes and improvements. I would say that at this point, I consider ourselves the new Cocotron upstream, but our Cocotron isn't really intended to be used outside of Darling; in particular, I'm sure I've long borken the Win32 code paths, as we only care about Linux, and the xcodebuild-based build, as we only care about our CMake build as a part of Darling.

Should anyone be interested in using our Cocotron for porting Cocoa apps to Windows (what the original Cocotron was intended to be used for), it would be possible to bring the Win32 backend up to date and build the Cocotron without the rest of Darling.

Basically, we're (well, speaking only for myself, I am) ready to be the new Cocotorn upstream, but it doesn't seem like there is any interest in that anymore.

[omeid]

Is supporting X11 worth it? Many distros and GUI frameworks are now supporting Wayland as a first class.