No, migration from SDL1.2 to SDL2.0. It’s an old document, but I’m assuming it is still valid and I particularly note that it says will be too late, not may be too late.
As previously discussed, I have to use SDL2, because SDL3 still doesn’t support the GLES 1.1 backend I need for the glLogicOp() function.
Ryan has hinted that support for GLES 1.1 in SDL3 may be coming, but I’m probably in a tiny minority in needing it. However, without it SDL3 cannot be advertised as a ‘replacement’ for SDL2.
After some investigation, it appears that the SIGSEGV crashes are caused by putting my app into the background - and then restoring it - whilst I have temporarily changed the GLES context using SDL_GL_CreateContext(). SDLActivity probably doesn’t know how to recreate the correct context on restoration.
I expect that, despite SDL_GL_CreateContext() being a documented API, it wasn’t anticipated that one would do it ‘on the fly’ in an Android app, as I sometimes do. I wonder of there’s some workaround I could incorporate in my code or if fixing the crash would require a change in SDLActivity.
there is the code that SDL use to store/restore gl context.
if it cannot restore it, it create a new one and send the EVENT SDL_EVENT_RENDER_DEVICE_RESET … maybe you need to catch this ?
and there is the hint SDL_HINT_VIDEO_EXTERNAL_CONTEXT
( if you create your own context and glLogicalOp, maybe you don’t need SDL_Renderer at all (just re-use the few functions that could help ..) and use SDL3 ? )
According to an AI chatbot, it is entirely possible for the current context to be destroyed by backgrounding the app, without the SDL_EVENT_RENDER_DEVICE_RESET event being sent. Specifically, if you have created any shaders, vertex buffers etc., they will not be automatically restored but neither will that event be received.
I use SDL_Renderer extensively, it is used nearly all the time in fact. The only occasions on which I switch to a different context are when rendering 3D or Shader graphics, which is unusual.
It may be that when user crashes have been registered they were indeed as a result of backgrounding the app whilst using 3D or shader graphics.
looking at the code, if you use SDL_HINT_VIDEO_EXTERNAL_CONTEXT,
SDL won’t save/restore your context, and you can do it manually using.
SDL_GL_GetCurrentContext() and SDL_GL_MakeCurrent().
but, it’s also written that saving/restore is a thread dependent… so this cannot be done within an EventWatch because it’s running on SDLActivity thread …
so you should read the event instead in the main thread.
Or you can try the approach before with the patch about SDL_CallEventWatchers()..
I’ve read elsewhere that this is unreliable, because the SDL_GLContext returned by SDL_GL_GetCurrentContext() isn’t a structure containing the actual context, it’s just a pointer to an area of memory that is very likely to have been destroyed/corrupted by going to the background and back.
/**
* \brief An opaque handle to an OpenGL context.
*/
typedef void *SDL_GLContext;
So when you ‘save’ a SDL_GLContext you’re not saving the context, you’re saving a pointer to the context, and we know that the context itself can be destroyed in Android by going into the background and back.
If that happens, and if SDL2 cannot restore or re-create the context, an SDL_RENDER_DEVICE_RESET event is issued. My understanding is that when handling it you actually have to re-create the context from scratch, you can’t ‘restore’ it from one you ‘saved’ earlier using SDL_GL_GetCurrentContext().
In practice I don’t think I ever get a SDL_RENDER_DEVICE_RESET event because on ‘modern’ Android, with Open GLES, it never happens.
As I said before, the shader, vertex buffers etc. do get destroyed, which is why my app crashes. SDL2 does not alert you to that happening, nor have I found a reliable way to detect that it has happened (I’ve tried a few different methods suggested by DeepSeek and Gemini AI, but with no luck).
The conclusion I’ve come to is that there is probably nothing I can do to prevent the crash. Fortunately not all Android devices suffer from this problem, my Samsung Galaxy tablet does but my OnePlus 10 phone doesn’t (and nor do iOS devices).
At least I now understand why it is happening, and I can warn my users to avoid the circumstances that cause the crash if they are concerned.
I don’t know, but at least, SDL_Render gles 1 has no shader inside …
so there are more things on your side which may be bug. how do you thing get destroyed ? are more error code check / print SDL internal GL error code
I can’t tell ‘remotely’ what my app is doing when it crashes. It may be drawing text or 2D graphics (requiring only SDL_Renderer and calls to glLogicOp), 3D graphics (having created a new GLES 1.1 context to use the Fixed Function Pipeline) or Shader graphics (with a GLES 2.0 context). The Play Store reports don’t reveal that kind of detail.
So it’s possible that the crash is happening only when It’s using a shader. The only ‘bug’ I’ve identified in my code is that I don’t currently disable my render target when I see the SDL_APP_WILLENTERBACKGROUND event. In my next release I’ll change that as follows:
case SDL_APP_WILLENTERBACKGROUND:
target = SDL_GetRenderTarget(renderer);
SDL_SetRenderTarget(renderer, NULL);
break;
Wonderful (if it works). To test it myself I would need to build sdl2-compat with that change, since my app has too many dependencies on SDL2 to work with native SDL3, but it works nicely with sdl2-compat.
I don’t even know whether sdl2-compat has been ported to Android yet.
I can’t. As I’ve explained, my app is highly dependent on SDL2 so can only take advantage of SDL3 features via sdl2-compat, which hopefully will be available for Android soon.
Meanwhile I will continue to use SDL2: it’s not deprecated and as far as I know there are no plans to deprecate it (after all, even SDL1 is still being used in current projects!).