I don’t know if the following is an SDL2 bug or MacOS bug. The problem is
that I fill a texture with red, then I fill it with blue (overwriting the
red), and then I unlock and present it. The result is mostly blue, but
with red near the top.
I reported a similar bug last year to Intel (see https://communities.intel.com/message/247607) for DirectX on Windows and
they called it an “OS issue”. I don’t know if the MacOS issue is related.
Anyway, I’d appreciate opinions on whether this is an SDL problem, my
misuse of SDL, or something to report to Apple.
This sounds a lot like this bug report: https://bugzilla.libsdl.org/show_bug.cgi?id=2973
If so, it?s likely a problem with the SDL_Render backend code in OS X.> On Nov 24, 2015, at 10:48 PM, Arch Robison <arch.d.robison at gmail.com> wrote:
I don’t know if the following is an SDL2 bug or MacOS bug. The problem is that I fill a texture with red, then I fill it with blue (overwriting the red), and then I unlock and present it. The result is mostly blue, but with red near the top.
…and this means that the GL happens to be updating from a texture that
you are literally in the middle of changing, because this races a little
(and SDL_LockTexture() isn’t actually locking anything).
This particular example shows incorrect behavior in a pathological case.
I can’t remember why we set it up this way; probably performance boosts
that might not be valid in modern times. We should revisit this code.
(and I could be wrong about all of this, having not checked, but
disabling the code in that #ifdef I linked to and rebuilding SDL will
probably make the problem vanish.)
–ryan.On 11/24/2015 09:48 PM, Arch Robison wrote:
I don’t know if the following is an SDL2 bug or MacOS bug. The problem
is that I fill a texture with red, then I fill it with blue (overwriting
the red), and then I unlock and present it. The result is mostly blue,
but with red near the top.
…and this means that the GL happens to be updating from a texture that
you are literally in the middle of changing, because this races a little
(and SDL_LockTexture() isn’t actually locking anything).