Skip to content
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

Open
bugaevc opened this issue Jan 1, 2018 · 7 comments
Open

OpenGL.framework #365

bugaevc opened this issue Jan 1, 2018 · 7 comments

Comments

@bugaevc
Copy link
Member

@bugaevc bugaevc commented Jan 1, 2018

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?
@bugaevc bugaevc added the GUI label Jan 11, 2018
bugaevc added a commit to darlinghq/darling-cocotron that referenced this issue May 27, 2018
See darlinghq/darling#365

TODO:
* Get rid of the few remaining glX calls
* Port CALayerContext
@woachk
Copy link
Contributor

@woachk woachk commented May 22, 2019

$ 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
Copy link
Member Author

@bugaevc bugaevc commented May 22, 2019

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
Copy link
Contributor

@woachk woachk commented May 22, 2019

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

@bugaevc
Copy link
Member Author

@bugaevc bugaevc commented May 22, 2019

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
Copy link
Member Author

@bugaevc bugaevc commented May 22, 2019

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
Copy link
Contributor

@CuriousTommy CuriousTommy commented May 24, 2019

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

@bugaevc
Copy link
Member Author

@bugaevc bugaevc commented May 24, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants