Add run-time check for EGL version on canvas creation (Issue #22325)
Ian McInerney
Apparently, some older vendor drivers (cough, NVIDIA, cough) forcefully remap the EGL library on a system to be different from the one used to build wx. This means that while wx has the config check to ensure the EGL library it builds against is version >1.5, in reality it could try to use a different EGL library at runtime, that might not be version >1.5. This was first noticed by a FreeBSD user because their install of KiCad was crashing with an error about undefined symbol eglGetPlatformDisplay - https://gitlab.com/kicad/code/kicad/-/issues/11369 and https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263209#c5.
It appears that EGL is supposed to provide a version at runtime if you query the eglQueryString with the EGL_VERSION name supplied. The EGL spec (https://www.khronos.org/registry/EGL/specs/eglspec.1.5.pdf, page 19) describes its behavior as:
The format of the EGL_VERSION string is:
<major version.minor version><space><vendor specific info>
Both the major and minor portions of the version number are numeric. Their values must match the major and minor values returned by eglInitialize (see section 3.2). The vendor-specific information is optional; if present, its format and contents are implementation specific.If dpy is EGL_NO_DISPLAY, then the EGL_VERSION string describes the supported client version. If dpy is a valid, initialized display, then the EGL_VERSION string describes the supported EGL version for dpy. The client version indicates that all EGL entry points which are needed for the supported client APIs are available at runtime, while > the display version indicates which EGL functionality is supported for a display.
I think it would be good to add a runtime check to the creation of the GL canvas with an EGL backend to ensure the runtime version of the library is at least the version we build against.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Scott Talbert
Seems like a reasonable thing to do. Any thoughts on what should happen if EGL is < 1.5 at runtime? Warning? Assert?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
I think we should use wxLogError() for this (BTW, the existing wxLogMessage() in wxGLContext ctor in src/unix/glegl.cpp should be an error too). Definitely not an assert because it's not a programmer's mistake, but something outside of the program control (and I suspect that many of the asserts in this file should be wxLogError()s too).
The main problem is that, AFAICS, if we detect EGL 1.5 during build but it's not available during run-time, then we won't have any OpenGL support at all, even if, in principle, we might still use classic OpenGL, as we would do if we failed to detect EGL in configure. So ideal would be to implement run-time fallback from EGL to OpenGL, but this would require much more changes...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Scott Talbert
Agreed, adding this error message might be only slightly more helpful than the undefined symbol errors the original user saw. Yes, the ideal answer is to be able to pick between GLX and EGL at runtime. I started to work on that at one point, but it was rather challenging to do with the design of wxGLCanvas.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
I think we discussed this in the past, but, in short, the solution would be to replace inheritance with composition, i.e. instead of inheriting wxGLCanvas from wxGLCanvasImpl which can be either wxGLCanvasEGL or wxGLCanvasX11, inherit it from wxGLCanvasBase and forward the implementation of its virtual methods to wxGLCanvasImpl* m_impl -- whose type could then be selected dynamically.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Scott Talbert
Yes, indeed, that was the approach we discussed and that I was attempting. However, it's a bit more complicated in that wxGLContext needs to be modified in a similar way, too.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Yes, it's not the first time the interplay between wxGL{Canvas,Context} creates extra problems :-( I guess we'd need some abstract wxGLFactory and concrete wxGLFactor{EGL,X11} that would be able to create both the canvas and the context consistent with each other...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ian McInerney
Looking at the uses of the symbol that was undefined in the reported bug, it is called from the static wxGLCanvasEGL::GetDisplay() function, which is in turn called from the constructor of wxGLContext. So a missing symbol like this prevents the construction of the context, so I feel it should be an error if the runtime version isn't at least the version we build against.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
@swt2c do you plan returning to this? I'd like to do something about it relatively soon (even if not immediately), but I wouldn't want to duplicate your work, so please let me know if I should just wait. TIA!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Scott Talbert
I don't have immediate plans to work on it - so if you've got the time and interest to work on it, feel free.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
It would be really nice to get this done before 3.3.0, even though it's not that simple...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ian McInerney
It would be really nice to get this done before 3.3.0, even though it's not that simple...
Do you mean the runtime version detection or the runtime switching (since this issue is for the runtime version check)? Because the version detection I thought was simple - we check the version and error.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
AFAICS giving an error is not that great, it's better than nothing, but switching to a working OpenGL implementation would be even better. So yes, I meant the runtime switching, but for me it's strongly related to this issue.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Fabrice de Gans
I would like to try my hand at implementing this. My thinking goes along those lines:
- As a short-term fix, output an error when the runtime EGL version is too old.
- Add basic tests for
wxGLCanvas. Maybe display a cube and check that the surface is drawn properly. - Properly select the appropriate backend at runtime. I think it would make the code cleaner if we added a delegate class to
wxGLCanvasfor GTK that defers to a GLX or EGL delegate picked at runtime rather than going through a factory class. This has the added advantage of not breaking the existing API customers.
I have some questions:
- The original comment states that the EGL version at runtime should be 1.5. Is this determined somewhere in the codebase already? Can this change in the future? If so, where should the minimum runtime requirement be set?
- Is the long-term goal that
wxUSE_GLCANVAS_EGLis going away once the implementation uses the right backend at runtime? In other words, is it safe to assume that EGL is going to be available at build time on all GTK-enabled platforms?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Scott Talbert
@Steelskin, this would be great, especially the runtime selection of GLX vs EGL. A delegate approach might be OK (would need to know more details), but keep in mind that you would need to handle wxGLContext and other wxGL* classes as well, as those have EGL/GLX specifics too.
The #22325 (comment) states that the EGL version at runtime should be 1.5. Is this determined somewhere in the codebase already? Can this change in the future? If so, where should the minimum runtime requirement be set?
The minimum EGL version is checked at compile time here:
https://github.com/wxWidgets/wxWidgets/blob/master/configure.ac#L3334
To be honest, we could probably support older versions of EGL, though. I just picked the latest when I implemented the original EGL support because it was new to wx.
Is the long-term goal that wxUSE_GLCANVAS_EGL is going away once the implementation uses the right backend at runtime? In other words, is it safe to assume that EGL is going to be available at build time on all GTK-enabled platforms?
Theoretically, it should still be possible to compile wxWidgets without EGL support at all, so wxUSE_GLCANVAS_EGL should probably stay.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
I would like to try my hand at implementing this. My thinking goes along those lines:
1. As a short-term fix, output an error when the runtime EGL version is too old. 2. Add basic tests for `wxGLCanvas`. Maybe display a cube and check that the surface is drawn properly.
Sorry, but how do you intend to do it non-interactively (I assume it's meant to be non-interactive because otherwise you could already do it with the cube sample)?
3. Properly select the appropriate backend at runtime. I think it would make the code cleaner if we added a delegate class to `wxGLCanvas` for GTK that defers to a GLX or EGL delegate picked at runtime rather than going through a factory class. This has the added advantage of not breaking the existing API customers.
The problem is the interplay between wxGLCanvas and wxGLContext, as they must both be of the same type and it wasn't obvious how to ensure that this was the case when I looked at it. Ideal would be to do it at compile-, rather than run-time, of course, i.e. you should be able to specify the type of the OpenGL implementation you want to use at run-time (knowing that wx would choose the one which works by default), but it shouldn't be possible to ask for EGL canvas using GLX context or vice versa.
* Is the long-term goal that `wxUSE_GLCANVAS_EGL` is going away once the implementation uses the right backend at runtime?
The long-term goal is to compile both GLX (as long as it's relevant) and EGL and anything else (WebGL?) in if available when building and provide the best, or the requested, one during run-time. wxUSE_GLCANVAS_EGL could still stay to allow disabling EGL support at build-time if somebody really doesn't want it for whatever reason, but it would be much less important than now because setting it wouldn't disable GLX support.
Thanks again for looking at this!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ian McInerney
To be honest, we could probably support older versions of EGL, though. I just picked the latest when I implemented the original EGL support because it was new to wx.
I think you'll have to change some code to do this, since the original function that caused this error is actually 1.5+: https://registry.khronos.org/EGL/sdk/docs/man/html/eglGetPlatformDisplay.xhtml
eglGetPlatformDisplay is supported only if the EGL version is 1.5 or greater.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Scott Talbert
To be honest, we could probably support older versions of EGL, though. I just picked the latest when I implemented the original EGL support because it was new to wx.
I think you'll have to change some code to do this, since the original function that caused this error is actually 1.5+: https://registry.khronos.org/EGL/sdk/docs/man/html/eglGetPlatformDisplay.xhtml
eglGetPlatformDisplay is supported only if the EGL version is 1.5 or greater.
Yes, but we could probably use eglGetDisplay instead.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Fabrice de Gans
Thanks for the comments, everyone. I'll try my best to address everything.
Sorry, but how do you intend to do it non-interactively (I assume it's meant to be non-interactive because otherwise you could already do it with the cube sample)?
I am thinking about dumping the GL surface content and comparing it to a reference image. There might be a few problems with this approach, in particular, optimizations might prevent anything from being actually drawn in headless mode. In this case, I think it might still be useful to have one automated test where we create the canvas and check that there's no error in the log. It's a bit too indirect for my tastes but it's better than nothing.
The problem is the interplay between
wxGLCanvasandwxGLContext, as they must both be of the same type and it wasn't obvious how to ensure that this was the case when I looked at it. Ideal would be to do it at compile-, rather than run-time, of course, i.e. you should be able to specify the type of the OpenGL implementation you want to use at run-time (knowing that wx would choose the one which works by default), but it shouldn't be possible to ask for EGL canvas using GLX context or vice versa.
Yes, I hit that issue while hacking at the problem. Also, wxGLContextAttrs and wxGLAttributes have different GLX/EGL implementations. That being said, at runtime, we only need to check if we need GLX or EGL once. This check can be cached so it's only done once. I'll show what I have in mind in a PR, I think it will be clearer and we can take it from there.
To be honest, we could probably support older versions of EGL, though. I just picked the latest when I implemented the original EGL support because it was new to wx.
Unfortunately, there are unfortunately more calls than eglGetPlatformDisplay that require a certain version of EGL. eglCreatePlatformWindowSurface is another. eglBindAPI requires 1.4 if called with EGL_OPENGL_API (as wx does). eglChooseConfig has minimum requirements listed for certain options (though, from a cursory glance, I don't think wx uses any of them).
I think, in the short term, requiring 1.5 is the safest way to proceed for now. I think it is not too much work to add version 1.4 support, with a gracious fallback to older APIs as needed.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Rafael Kitover
We need to think about how we are going to handle the necessary API changes for a dynamic GLCanvas implementation.
With no changes, the following will happen:
- An X11 app that does not support EGL and does not check wxUSE_GLCANVAS_EGL will continue to work under X11 with no changes. It would not work under Wayland and would have to run under xwayland, but that can't be helped.
- An app supporting EGL that checks for wxUSE_GLCANVAS_EGL but does not also check for Wayland will break under X11 because it will be the GLX GLCanvas instance.
It would probably be good for the new API to allow using the EGL GLCanvas under X11 as well, both statically and dynamically.
It's probably not possible to make this completely backwards compatible.
I'm thinking one possible solution would be to allow an EGL app to define something like:
#define wxPREFER_GLCANVAS_EGL
, this would also allow distro package maintainers to easily fix apps which have not been updated.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Can we reinterpret the existing wxUSE_GLCANVAS_EGL as wxPREFER_CANVAS_EGL to avoid introducing yet another build option? I.e. wxUSE_GLCANVAS_EGL would continue to mean "wxGLCanvas is wxGLCanvasEGL", but it probably wouldn't be defined by default and could be deprecated. Instead, we'd add wxUSE_EGL (and wxUSE_GLX?) that could be used to turn off EGL (and GLX?) entirely at build time but when they are both on, wxGLCanvas would dynamically select EGL implementation under Wayland and GLX one under X.
Does this seem doable?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Rafael Kitover
I agree with this, we can leave wxUSE_GLCANVAS_EGL undefined and allow it to be used to select the EGL wxGLCanvasEGL always at build time. This will also allow package maintainers to fix issues easily.
I'm unclear on how you want wxUSE_EGL and wxUSE_GLX to behave. If they are both set in the config header, how would they be overridden by compiler flags? They could be booleans instead of defined/undefined, then the config header could check for them being already defined.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
I agree with this, we can leave
wxUSE_GLCANVAS_EGLundefined
Sorry, a small correction: all wxUSE_XXX symbols must be always defined as 0 or 1, so we can't leave it undefined. But we can use it as I wrote if it's defined as 1.
I'm unclear on how you want
wxUSE_EGLandwxUSE_GLXto behave. If they are both set in the config header, how would they be overridden by compiler flags?
They wouldn't, why should they be overridden? They would be both defined as 1 if the corresponding functionality is available at configure time but could be forced to be 0 using configure/cmake options if, for whatever reason, you don't want to use the corresponding backend.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Rafael Kitover
Sorry, a small correction: all wxUSE_XXX symbols must be always defined as 0 or 1, so we can't leave it undefined. But we can use it as I wrote if it's defined as 1.
Sorry, I forgot how this works.
To clarify, I'm not talking about a build option for wx, but a macro that can be set at build time for an app using it.
So what I am proposing is that wxUSE_GLCANVAS_EGL would always be defined this way in setup.h:
#ifndef wxUSE_GLCANVAS_EGL # define wxUSE_GLCANVAS_EGL 0 #endif
This way, an unpatched app supporting both GLX and EGL would not break when given a GLX wxGLCanvas under X11. Or an app that is GLX-only and checks if EGL is defined to turn off OpenGL functionality.
For an EGL-compatible app, the only change necessary would be for the package maintainer to pass -DwxUSE_GLCANVAS_EGL=1 as a compiler flag, or for upstream to define this in their headers.
This would be in-addition to the new dynamic APIs to check/set the instance of wxGLCanvas.
Not a perfect solution, but I can't think of a better one right now.
They wouldn't, why should they be overridden? They would be both defined as 1 if the corresponding functionality is available at configure time
Yeah, that makes sense.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Rafael Kitover
In our app, the place where we have divergent OpenGL code for GLX/EGL is handling vsync. And I'm not sure I'm doing this correctly right now. The GLX vsync method does not work in Wayland under EGL, but it may work in X11 under EGL, I need to test this.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
To clarify, I'm not talking about a build option for wx, but a macro that can be set at build time for an app using it.
Ah, I see, thanks. We shouldn't call it wxUSE_XXX then though, as this naming convention is (informally) reserved for wx build options. Unfortunately we don't really have any consistent naming convention for the options affecting wxWidgets headers set by the application code. We have wxNO_IMPLICIT_WXSTRING_ENCODING and similar for disabling dangerous parts of API, but nothing for actually selecting between possibilities, unless I'm forgetting something.
So what I am proposing is that
wxUSE_GLCANVAS_EGLwould always be defined this way insetup.h:
So I'd rather call this wxALLOW_GLCANVAS_EGL or something similar (wxPREFER_EGL? wxSUPPORTS_EGL?) and either define it or not: if it's defined, wxGLCanvas would use EGL (if available) under X11 but otherwise (and so by default) it would use GLX there.
Not a perfect solution, but I can't think of a better one right now.
Yes, all this is rather baroque, but, as you say, it seems to be the only way to preserve compatibility while also allowing to opt into using EGL.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ian McInerney
Yes, all this is rather baroque, but, as you say, it seems to be the only way to preserve compatibility while also allowing to opt into using EGL.
I can't fully follow the proposal here. Why does this need more complicated then the default backend being GLX, which would be the equivalent to how some distro packages are configured now (and was the default in prep 3.2 versions), and then the application requests the EGL backend if desired?
Adding logic that tries to determine what the application wants and prefers would seem to me to be possibly be bad also. Take for example applications that link against GLEW. GLEW must be compiled against either GLX or EGL and the same shared/static library can't support both. This means an application linking against GLEW is only compatible with a single implementation. So the idea that an application "prefers" EGL in this case is a bit of a misnomer, because in reality the application must use EGL, otherwise it will crash in its GLEW calls.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Scott Talbert
I can't fully follow the proposal here. Why does this need more complicated then the default backend being GLX, which would be the equivalent to how some distro packages are configured now (and was the default in prep 3.2 versions), and then the application requests the EGL backend if desired?
GLX doesn't work on Wayland, so applications would have to force X11 in order to work, as they do now, so that wouldn't be much of an improvement.
I can't fully follow the proposal here. Why does this need more complicated then the default backend being GLX, which would be the equivalent to how some distro packages are configured now (and was the default in prep 3.2 versions), and then the application requests the EGL backend if desired?
In that case, the application would either need to force X11 (if it uses the GLX version of GLEW), or use the wx option to force using EGL w/X11 (whatever it will be called if it uses the EGL version of GLEW).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Rafael Kitover
So I'd rather call this wxALLOW_GLCANVAS_EGL or something similar (wxPREFER_EGL? wxSUPPORTS_EGL?) and either define it or not: if it's defined, wxGLCanvas would use EGL (if available) under X11 but otherwise (and so by default) it would use GLX there.
So how about we do this in setup.h:
#ifdef wxPREFER_EGL # define wxUSE_GLCANVAS_EGL 1 #else
# define wxUSE_GLCANVAS_EGL 0 #endif
, the rationale for wxUSE_GLCANVAS_EGL being set to 0 by default being compatibility with GLX apps.
This is of course in addition to the dynamic APIs we will add for all of this.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
I think we need the API allowing to choose the OpenGL implementation dynamically first before choosing the defaults just to fix the ideas because right now I'm not sure what does/will wxUSE_GLCANVAS_EGL do any more and so I can't say whether the above is correct. I suspect it isn't because wxUSE_XXX generally affect the ABI and so shouldn't be changed like this but, again, I'm not really sure any more.
I still think that we need:
- A way to explicitly use either
wxCanvasGLXorwxCanvasEGLin the application code and a way to check if they're supported in the current environment, so that the application could handle the failure to create them at least somewhat gracefully. - A way to say "use whatever works in the current environment" and then a possibility to query whether GLX or EGL is being effectively used.
- A way to map to map
wxGLCanvasto either GLX, EGL or "whatever works" version at build time. - Some way to disable EGL (and maybe GLX) support completely at build-time: this is trivial but mentioning it for completeness.
Do we all agree about this and/or is something here extraneous or missing?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Manolo-ES
According with the title of this thread, (please, read "run-time" before every x.) I'd say we need:
- A way to check at if GLX and/or EGL are supported. This means that at compile time both branches dedicated code should be compiled (those provided by the OS).
- A way to inform the user which GLX/EGL is/are available.
- A way to allow the user to select (or prefer) GLX or EGL. Also, we should decide the default.
- A way to make new things have default behavior for GLX, just for backwards compatibility.
IMHO 1. can be achieved by searching for GL libs. But they can't be linked for sure in wx nor in user app, because we don't know if they exist. So, at runtime we can search for the required lib (see 2. 3. ) and retrieve GLX/EGL calls from that lib.
For the wx code I think composition (wxGLX_imp, wxEGL_imp) is better that wxGLCanvas derived classes.
Finally, don't forget that EGL may also be available for MSWindows.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Rafael Kitover
@vadz I agree with your points.
Let me explain my reasoning for the code snippet above.
- We are aiming for compatibility with GLX apps, so we want the default for
wxUSE_GLCANVAS_EGLto be0, in case they check it. - As you suggested, it will be deprecated in favor of new macros and APIs, so we can break the rule about it being ABI-specific.
- We want a macro that can be used at app build-time to easily fix EGL apps which have not yet been updated.
This is the best solution I can think of right now for this specifically after discussing this with you, unless someone suggests a better one.
@Steelskin you're implementing this, what do you think?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Fabrice de Gans
Sorry I have been busy the past few weeks. I'm going to try to summarize the discussion and how I intend to move forward.
It is apparent that we are going to need some way of specifying the preferred backend at runtime, which should be done via a set of new APIs, this is my suggestion:
- Add an associated enumeration to
wxGLCanvas, which specifies a number of available implementations:
enum class wxGLCanvasBackend { None, // If built with no OpenGL support. MSW, Cocoa, IPhone, QT, GLX11, EGL };
- Add a number of static functions to
wxGLCanvas(technically onwxGLCanvasBase) to query the active implementation, the available implementations at runtime and set the preferred implementation:
class WXDLLIMPEXP_GL wxGLCanvasBase : public wxWindow { public: // [...] // Returns the currently active wxGLCanvas backend. wxGLCanvasBackend GetActiveBackend(); // Sets the preferred wxGLCanvas backend. Returns the newly active wxGLCanvas backend, // which may be different from `preferred_backend`. wxGLCanvasBackend SetPreferredBackend(wxGLCanvasBackend preferred_backend); // Returns the list of available wxGLCanvas backends at runtime. std::vector<wxGLCanvasBackend> GetAvailableBackends(); };
- Regarding implementation, there are many classes involved around OpenGL and changing them at runtime will lead to issues. I propose we explicitly document that changing the active backend at runtime is undefined behavior. I can also look into checking at runtime if any
wxGL*object is live at runtime when changing the backend. - Regarding the default, I'll have to do a few tests for that but my thinking is, prefer EGL if the stars align, fallback to GLX if not, error out if on Wayland with EGL < 1.5 (we can fix that later, I think we may be able to support 1.4 with a few more changes).
All of this has the benefit of not breaking any existing user since these are new APIs that are safe-ish to ignore. In addition, it should make it easier to provide different backends down the line, as mentioned by @Manolo-ES.
WDYT?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
I don't know if it makes sense to support using EGL and GLX together in the same application (for the different windows, of course)? If it is possible at all, I'm all but sure that someone will want to do it because they're using some other library which only supports EGL but they have legacy code which only works with GLX (or vice versa). And if we do want to support this, then we need to have an API to select the backend for this particular wxGLCanvas, e.g. a factory function creating wxGL{Canvas,Context} for the given backend.
But it's obviously much simpler if we don't and in this case the proposed API would be enough and, of course, much better than nothing.
Concerning the API details, I'm not really sure we want to have MSW and other backends choices here, SetPreferredBackend(wxGLCanvasBackend::MSW) is useless under MSW (there are no other choices there) and can only give an error everywhere else. I'd avoid being overly generic here and make all these functions Unix-only (we'd add some new wx/unix/glcanvas.h) as I think you're going to have some Linux-specific code anyhow if you're using them and so it's not a problem to put them in Linux-only part of the code. Or we could still have them in wxGLCanvasBase itself but just make them do nothing under the other platforms.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Rafael Kitover
@Steelskin wrote:
Regarding the default, I'll have to do a few tests for that but my thinking is, prefer EGL if the stars align, fallback to GLX if not, error out if on Wayland with EGL < 1.5 (we can fix that later, I think we may be able to support 1.4 with a few more changes).
Just to reiterate here, we are also trying to do this. That is, we want the default under X11 to be GLX for apps not using the new APIs/macros.
And on that point, what do you think of my code snippet to deal with the wxUSE_GLCANVAS_EGL macro compatibility?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
@rkitover Your code snippet can't work without many more changes AFAICS. Currently you compile the library either with GLX xor EGL support, you can't have them both and this is what needs to change.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Rafael Kitover
Yeah I get that, I mean when those changes are implemented, however they are implemented. Part of my interest in this is helping distro maintainers who are currently disabling EGL support for compatibility.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Sorry for misunderstanding you.
The plan is definitely to allow distro maintainers to have one version which would work for all cases. It's just that doing it is not really trivial...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Rafael Kitover
I think we should also fallback to GLX when EGL fails to initialize, if it's available. Just ran into such a failure myself.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
The idea is that availability check would return false if EGL can't be initialized. Or is there some case in which we can't check for this beforehand? Why exactly does it fail in your case?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Rafael Kitover
In my case it failed to initialize because I had no hardware OpenGL drivers because I was using nix without nixGL, so nevermind, this ability would probably not be useful.
On the other hand, some kind of API to query "is OpenGL support fully available at runtime" would probably be nice.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
dsa-t
Is there a reason why EGL 1.5 is required?
eglGetPlatformDisplay and eglCreatePlatformWindowSurface are both supported in EGL_EXT_platform_base extension. wx already has a dynamic loader for eglGetPlatformDisplay.
Some KiCad users still use implementations with only EGL 1.4 support (https://gitlab.com/kicad/code/kicad/-/issues/16442)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
@dsa-t If you can test that things actually work with EGL 1.4, I'd be glad to apply the trivial patch relaxing the check. From just reading the code, it does look like it should work with it since the changes of #23855.
Are the other problems described in KiCad issue KiCad-specific?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
dsa-t
Check this code:
wxLogError("Logged Error"); wxMessageDialog dlg( nullptr, "Message Dialog", "Information", wxOK | wxCENTRE | wxRESIZE_BORDER | wxICON_INFORMATION | wxSTAY_ON_TOP ); dlg.ShowModal();
The message dialog will show up on top, but not clickable. The logged message dialog will be hidden behind and clickable/focused.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
dsa-t
There's a patch to enable EGL 1.4 support, but we couldn't test it sufficiently:
dsa-t@6b388c5
https://gitlab.com/kicad/code/kicad/-/issues/16442#note_1740158088
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
aviatorhh
There's a patch to enable EGL 1.4 support, but we couldn't test it sufficiently:
dsa-t@6b388c5 https://gitlab.com/kicad/code/kicad/-/issues/16442#note_1740158088
Just to give a feedback from somewhere else.
It is a success doing wx326 (incl. patch from above) with OpenCPN on a RPi5. Before this patch I had to disable dtoverlay=vc4-kms-v3d in the config.txt to avoid this issue.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
dsa-t
dsa-t left a comment (wxWidgets/wxWidgets#22325)@vadz perhaps the above EGL 1.4 patch can be picked into wx then?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#22325)perhaps the above EGL 1.4 patch can be picked into wx then?
I've tried using the patch as it is, but this resulted in the failure to create the surface when using X11 (at least with Sway XWayland implementation), so I've change it to still call eglCreatePlatformWindowSurface() when using 1.5 (instead of eglCreateWindowSurface() that was called before if eglCreatePlatformWindowSurfaceEXT() was not available).
Please see #25986 and let me know if this works for you — if it does, it should be merged and could possibly be backported to 3.2 too.
TIA!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Closed #22325 as completed via 602b80d.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.