MacOS RedFlicker bug

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.

Complete SDL2 code for the example and how to build it are at
https://github.com/ArchRobison/RedFlicker .

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.

  • Arch D. Robison

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.

Complete SDL2 code for the example and how to build it are at https://github.com/ArchRobison/RedFlicker https://github.com/ArchRobison/RedFlicker .

I reported a similar bug last year to Intel (see https://communities.intel.com/message/247607 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.

  • Arch D. Robison

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

This happens because on Mac OS X, we set it up so we are sharing client
memory with the GPU:

https://hg.libsdl.org/SDL/file/69a5f3a540af/src/render/opengl/SDL_render_gl.c#l752

…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.

Thanks for the info. I ended up working around the problem by using two
textures and alternating between them.

  • ArchOn Mon, Nov 30, 2015 at 11:40 PM, Ryan C. Gordon wrote:


This happens because on Mac OS X, we set it up so we are sharing client
memory with the GPU:

https://hg.libsdl.org/SDL/file/69a5f3a540af/src/render/opengl/SDL_render_gl.c#l752

…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).