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
OpenGL.framework #365
Comments
See darlinghq/darling#365 TODO: * Get rid of the few remaining glX calls * Port CALayerContext
$ swift test.swift 2019-05-22 13:42:16.591 swift[194:3e8] FreeType font face is not scalable Isn't totally functional too.. |
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. |
@bugaevc what's the setup needed to test? copying over the _dri.so(s) doesn't seem to be enough on its own. |
Symlink over enough of |
If you get it to work, you'll also need some workaround for #368; the easiest is to patch |
Will this work also be upstreamed to Cocotron, or would it be too Darling specific? |
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. |
Is supporting X11 worth it? Many distros and GUI frameworks are now supporting Wayland as a first class. |
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 aboutX11Window
s 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.
gl*
symbols from the nativelibGL
CGL*
andgl*
APIseglGetDisplay
andeglCreateWindowSurface
eglGetConfigAttrib()
to choose the visual for X11 and pass it back to AppKitwl_egl_*
stuff?The text was updated successfully, but these errors were encountered: