We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Clarification:

Presence of WGL_EXT_create_context_es{,2}_profile could mean that an ES 3.x profile is supported. The problem is that if it is not, the OpenGL context creation fails and there is no attempt to load a libegl.dll or libGLESv2.dll.

I am working on fixing this issue and have questions about the expected usage of SDL by apps. I need to understand this in order to create the best solution.

In most of the *CreateWindow, *_GL{,ES}_CreateContext and *_GL{,ES}_LoadLibrary functions, for platforms that support both OpenGL and OpenGL ES, there is code that checks the profile mask, unloading the current library and loading the other, if it doesn't match.

For example in SDL_x11opengl.c X11_GL_LoadLibrary

    if (_this->gl_config.profile_mask == SDL_GL_CONTEXT_PROFILE_ES && 
        ! _this->gl_data->HAS_GLX_EXT_create_context_es2_profile ) {
#if SDL_VIDEO_OPENGL_EGL
        X11_GL_UnloadLibrary(_this);
        ...
#endif
    }

and in SDL_x11opengles.c in X11_GLES_LoadLibrary

    if (_this->gl_config.profile_mask != SDL_GL_CONTEXT_PROFILE_ES) {
        #if SDL_VIDEO_OPENGL_GLX
        X11_GLES_UnloadLibrary(_this);
        ...
        #endif
    }

For the case of the *LoadLibrary functions, I presume this is because the application could call SDL_GL_LoadLibrary at anytime and you are trying to protect applications from themselves. Is this true? Is there another reason?

For the case of the *_CreateWindow I suppose this is because you do not know which library might be loaded at the time SDL_CreateWindow is called.

For the *{GL,ES}_CreateContext functions the reason is not clear at all. The documentation says that the PROFILE_MASK, MAJOR_VERSION and MINOR_VERSION attributes must be set *before* the window is created and the window must be created before SDL_GL_CreateContext is called. So why are the checks necessary?

An application that changed attributes between SDL_CreateWindow and SDL_GL_CreateContext is not following the rules.

If the application was to create a second window with different attributes, these checks would result in a different library being loaded, breaking rendering in the first window.

I have just spotted an inconsistency between X11_GL_LoadLibrary and WIN_GL_LoadLibrary. The former, after calling GL_InitExtensions() checks for PROFILE_ES and if so is the necessary extension supported. If not, it unloads the GL library and loads the GLES library. The latter simply loads the GL library.

Because WIN_GL_CreateContext does the test and unload/load the end result for the application is much the same. But it is confusing.

It seems simpler to just test this in LoadLibrary and ensure the correct library is loaded and remove the tests elsewhere. Hopefully I will get answers to my questions in comment 2 that can guide me.

I have just submitted a patch in bug #2570 that fixes this. Please incorporate it into SDL.

While working on the fix I found some additional problems which I also fixed:

- The correct extension name to check is EXT_create_context_es_profile
  EXT_create_context_es2_profile only indicates support for ES2 profiles.
- EXT_create_context_es_profile does not support OpenGL ES 1 profiles.
  The patch makes SDL load libGLES_CM and libEGL if ES 1 is specified.


I also spotted several differences between the WIN and X11 implementations that cause application portability problems for several corner cases. That is an app may work on WIN and fail or X11 or vice-versa. I may file a new bug for those.

Your patch is in, please see my comments on bug 2570
https://hg.libsdl.org/SDL/rev/36f40b8cc979

Please do file bugs for the other portability problems you noticed.

I'm going to ping Ryan to chime in on comment 2, as I'm not sure of the intricacies of that.

Thanks!

I think the loading/unloading of libraries enables the chance to open a window in OpenGL, if that fails (no OpenGL of x version available for example), you can try with OpenGL ES, or the other way around, or have a test app that deals with several types of OpenGL contexts in sequence (even though as you mentioned having them loaded concurrently will result in a problem).

(In reply to Sam Lantinga from comment #5)
> Please do file bugs for the other portability problems you noticed.
> 

It was a long time ago. I will look for the notes I made at the time. If I find them, I'll file the bugs.

(In reply to Sam Lantinga from comment #5)
> I'm going to ping Ryan to chime in on comment 2, as I'm not sure of the
> intricacies of that.

I think Mark's reading of this is correct and we've probably never had an app that needed to switch libraries at all, let alone after creating a window, so it's probably just a well-intentioned bug.

--ryan.

The fix to this bug introduced bug 3725

(In reply to Sam Lantinga from comment #9)
> The fix to this bug introduced bug 3725

Bug #3725 is resolved now, so I'm resolving this one too (or should we leave this open?).


--ryan.