| Summary: | Prefering Metal above OpenGlES2 crashes our App on SDL_DestroyTexture | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Dominik Reichardt <sdl-bugzilla> |
| Component: | render | Assignee: | Alex Szpakowski <amaranth72> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | major | ||
| Priority: | P2 | CC: | bugmaster, icculus |
| Version: | HG 2.0 | Keywords: | target-2.0.10 |
| Hardware: | iPhone/iPod touch | ||
| OS: | Other | ||
Tagging a bunch of bugs with "target-2.0.10" so we have a clear list of things to address before a 2.0.10 release. Please note that "addressing" one of these bugs might mean deciding to defer on it until after 2.0.10, or resolving it as WONTFIX, etc. This is just here to tell us we should look at it carefully, and soon. If you have new information or feedback on this issue, this is a good time to add it to the conversation, as we're likely to be paying attention to this specific report in the next few days/weeks. Thanks! --ryan. The culprit was that to get the HighDPI window size, we were using SDL_GL_GetDrawableSize() but that is not compatible if the window was created using Metal.
To keep compatible with either OpenGL and Metal you need to use SDL_GetRendererOutputSize() instead.
As SDL_GL_GetDrawableSize() is often referenced for getting the HighDPI window size, I suggest either to break more gracefully with an actual error ("using OpenGL function SDL_GL... with metal renderer") or maybe handle it another way.
Alex, can you take a look at this? Thanks! Unfortunately the function signature for SDL_GL_GetDrawableSize doesn't allow for success/error indication. I can/should still make it not crash, but I'm not sure what to do to make sure people know it doesn't work, at runtime. I've put in a fix to make SDL_GL_GetDrawableSize return the window's (DPI-scaled) size if there's no GLES view on iOS, here: https://hg.libsdl.org/SDL/rev/96bca5da4965 The reason why it was crashing for you, from what I understand, is you didn't check the w/h params after calling the function and always expected them to be initialized with a value. In my opinion those params *shouldn't* be filled in if there's no GL context, but since the function signature doesn't allow for easy error checking I can see why it'd be confusing. That said, SDL_GetWindowSize behaves similarly to how SDL_GL_GetDrawableSize behaved before my commit (it doesn't fill in the w/h parameters if the given window is invalid), and it doesn't return an error value either. Thanks for looking into it. But sorry, to say, SDL_GetWindowSize is not a good replacement for SDL_GL_GetDrawableSize when the aim is to get the HighDPI size on iOS (see https://wiki.libsdl.org/SDL_GL_GetDrawableSize). Only SDL_GetRendererOutputSize will return the correct size as an alternative (but it's getting its value from *renderer not *windows). *Maybe* SDL_GL_GetDrawableSize can check if it is even in a GL context and print an error along with the garbage, so developers can see what is going wrong. Or the metal renderer needs a similar function and either gets called by something like SDL_GetDrawableSize(windows, w, h). But that is probably way out of scope for the SDL 2.0.10 release (and SDL_GetRendererOutputSize is a good alternative). OR the Wiki entry https://wiki.libsdl.org/SDL_GL_GetDrawableSize just needs to make it clear explicitly that it will only work in the GL context and SDL_GetRendererOutputSize is a good alternative. Before the metal renderer was a thing we just didn't need to worry as it was just working, so I was surprised but in the end our fault :) (In reply to Dominik Reichardt from comment #6) > But sorry, to say, SDL_GetWindowSize is not a good replacement for > SDL_GL_GetDrawableSize when the aim is to get the HighDPI size on iOS (see > https://wiki.libsdl.org/SDL_GL_GetDrawableSize). Of course not, calling SDL_GL_GetDrawableSize without having called SDL_GL_CreateContext is a user error. :) > *Maybe* SDL_GL_GetDrawableSize can check if it is even in a GL context and > print an error along with the garbage, so developers can see what is going > wrong. I could make it call SDL_SetError internally, but SDL_GetError is only meant to return a legit error after a function returns with an error value (for example, other parts of SDL's backend code set error messages internally before falling back to a successful path, and end up returning success and those error messages they set are not indicative of an actual error unless a function returned -1 or NULL). Unfortunately SDL_GL_GetDrawableSize has no return value and we can't add one because we need to preserve SDL's ABI. > Or the metal renderer needs a similar function and either gets called by > something like SDL_GetDrawableSize(windows, w, h). But that is probably way > out of scope for the SDL 2.0.10 release (and SDL_GetRendererOutputSize is a > good alternative). SDL_GL_GetDrawableSize should only and always be called when using a direct OpenGL context. SDL_GetRendererOutputSize should only and always be used when using the SDL_Render API. > OR the Wiki entry https://wiki.libsdl.org/SDL_GL_GetDrawableSize just needs > to make it clear explicitly that it will only work in the GL context and > SDL_GetRendererOutputSize is a good alternative. It would be good to make it clearer on the wiki that SDL_GL_GetDrawableSize is only valid when using SDL_GL_CreateContext, yes. |
Changset 12482 crashes Exult on iOS with an Assertion failure "Assertion failure at SDL_DestroyTexture (....SDL_render.c:3092, triggered 1 time: 'texture && textrue->magic == &texture_magic')" when we call SDL_DestroyTexture on our surface. In our code we only use surface with (very simplified and out of context of our code): screen_window = SDL_CreateWindow("", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, w, h, flags); screen_renderer = SDL_CreateRenderer(screen_window, -1, 0); screen_texture = SDL_CreateTexture(screen_renderer, desktop_displaymode.format, SDL_TEXTUREACCESS_STREAMING, w, h); Interestingly this assertion did not show up when running it in the iOS simulator, only directly on the device.