-
Notifications
You must be signed in to change notification settings - Fork 513
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
Clarification on X11/GLX versus Wayland/EGL #1923
Comments
Yes. There have been requests to make the GLCanvas backend selectable at runtime, but unfortunately, that's a rather complicated change. I've started working on it but I haven't gotten very far yet.
EGL is the default, so yes, that's how the bundled copy of wxWidgets gets compiled.
So you need to support GLCanvas over an SSH session? Not sure about that honestly - EGL also supports X11.
Yes, although, you can still use that to force using X11 with EGL too. |
Hi @swt2c, thanks for the reply. I can't find any definitive information, but the internet is suggesting that EGL instructions cannot be forwarded over a network in the same way that GLX instructions can (our servers are headless, with no GPU or X server). But this is not a major issue, as we can pin to 4.1.0, or build our own version of wxpython. And I seem to be having some success with combining Thanks again for the response! |
I'll take this as a +1 also to implementing runtime selection for EGL vs GLX as it seems there are growing requests for that. |
If it were an option I'm sure I'd use it, but I don't want to unnecessarily cause extra work for you :) |
Hi @swt2c - can you please reopen this issue? While it's great that @pauldmccarthy "seems to be having some success", being able to switch between EGL and GLX at runtime would still be helpful. |
I can, but the work really needs to be done in wxWidgets and not here in wxPython. So, really a Trac ticket should be opened: |
Considering that the way of making this work is dependent on whether it was built with GLX or EGL, is it possible to check at runtime which build is being used? |
@carandraug I spent some time looking into this a few weeks back (trying to determine whether a particular wxWidgets build was compiled to use EGL or GLX), and unfortunately was not able to find a direct or robust solution. The best I came up with was to test for the presence of a GLX-specific GL extension, e.g. A simple static function which indicates whether GLX or EGL is in use would be super handy. edit fwiw, the |
If this was wxWidgets we'd have access to the preprocessor flags. Maybe it makes sense to have a dict wit those flags. Something that then we could use as in There is a list of them here |
Howdy,
This is not an issue - rather, I was hoping for official clarification on the current situation with regard to the use of X11/GLX versus Wayland/EGL.
I am in the lucky situation of being the maintainer of a wxPython+PyOpenGL application with users who routinely work on remote servers using X11 over SSH, so my query specifically relate to the use of
GLCanvas
.I think I've figured things out, but I would appreciate if somebody could confirm whether the following statements are accurate:
As of this PR, the GL initialisation library used by the
GLCanvas
class (either GLX or EGL) has become a compile-time choice. So a version of wxWidgets/wxPython compiled against EGL cannot be made to use GLX, and vice versa.The wxPython 4.1.1 binary wheels released at https://extras.wxython.org have been compiled such that
GLCanvas
uses EGL.In order to support X11 over SSH, I'll need to either stick with wxPython 4.1.0, or build my own version of wxPython, such that wxWidgets is configured and built with
--disable-glcanvasegl
.As an aside, I'm also guessing that the previously suggested workaround of using
GDK_BACKEND=x11
to allow a wxPython/OpenGL application to work in a Wayland environment is now only relevant to GLX builds of wxWidgets.Does all of this sound about right? Thanks!
The text was updated successfully, but these errors were encountered: