wxWidgets / Phoenix

wxPython's Project Phoenix. A new implementation of wxPython, better, stronger, faster than he was before.
http://wxpython.org/
2.25k stars 513 forks source link

Clarification on X11/GLX versus Wayland/EGL #1923

Open pauldmccarthy opened 3 years ago

pauldmccarthy commented 3 years ago

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:

  1. 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.

  2. The wxPython 4.1.1 binary wheels released at https://extras.wxython.org have been compiled such that GLCanvas uses EGL.

  3. 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.

  4. 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!

swt2c commented 3 years ago

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.

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.

The wxPython 4.1.1 binary wheels released at https://extras.wxython.org have been compiled such that GLCanvas uses EGL.

EGL is the default, so yes, that's how the bundled copy of wxWidgets gets compiled.

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.

So you need to support GLCanvas over an SSH session? Not sure about that honestly - EGL also supports X11.

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.

Yes, although, you can still use that to force using X11 with EGL too.

pauldmccarthy commented 3 years ago

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 PYOPENGL_PLATFORM=egl and LIBGL_ALWAYS_SOFTWARE=1, for software-based rendering.

Thanks again for the response!

swt2c commented 3 years ago

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.

pauldmccarthy commented 3 years ago

If it were an option I'm sure I'd use it, but I don't want to unnecessarily cause extra work for you :)

chloesack92 commented 2 years ago

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.

swt2c commented 2 years ago

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: https://trac.wxwidgets.org/

carandraug commented 1 month ago

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?

pauldmccarthy commented 1 month ago

@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. GLX_ARB_multisample (which was added to core GLX 1.4, so should be present on all systems). if this extension is available, then you're using GLX; if not, you're using EGL. "Works on my machine", but I'm not sure how portable it is.

A simple static function which indicates whether GLX or EGL is in use would be super handy.

edit fwiw, the GDK_BACKEND=x11 environment variable is required if you are trying to use a GLX build under Wayland.

carandraug commented 1 month ago

A simple static function which indicates whether GLX or EGL is in use would be super handy.

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 wx.wxWidgets_symbols["wxHAS_GL_CANVAS_EGL"] or wx.wxWdgets_symbols["wxHAS_3STATE_CHECKBOX "]

There is a list of them here https://docs.wxwidgets.org/3.2/page_cppconst.html but does list the flag for GL/EGL