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.

Bug 5372

Summary: GLES2 render backend uses wrong pixel format for textures
Product: SDL Reporter: Ryan C. Gordon <icculus>
Component: renderAssignee: Ryan C. Gordon <icculus>
Status: RESOLVED INVALID QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2    
Version: 2.0.13   
Hardware: x86_64   
OS: Linux   

Description Ryan C. Gordon 2020-12-01 01:54:09 UTC
In GLES2_CreateTexture:

    switch (texture->format)
    {
    case SDL_PIXELFORMAT_ARGB8888:
    case SDL_PIXELFORMAT_ABGR8888:
    case SDL_PIXELFORMAT_RGB888:
    case SDL_PIXELFORMAT_BGR888:
        format = GL_RGBA;
        type = GL_UNSIGNED_BYTE;
        break;
    // ...

...this causes problems, though, if you created a texture with SDL_PIXELFORMAT_ABGR8888, since it will treat the data uploaded with SDL_UpdateTexture as RGBA instead of ABGR, swizzling the colors.

This might be a simple fix in SDL, but I have to check if there's a reason this was done (is only GL_RGBA is reliably available to GLES? etc).
Comment 1 Ryan C. Gordon 2020-12-01 02:40:13 UTC
Turns out GLES doesn't support many texture formats, which is why these all get gated through GL_RGBA.

In GLES2_TexSubImage2D, we already create a temporary copy of the data to change its packing; instead, we can probably just use SDL_CreateRGBSurfaceFrom with the incoming pixels then use SDL's normal conversion routines to handle packing _and_ format adjustment, replacing the existing code outright.

--ryan.
Comment 2 Ryan C. Gordon 2020-12-01 08:44:17 UTC
Wait, this might be an Emscripten or Firefox bug, it doesn't reproduce with the GLES2 renderer on X11, and upon closer inspection, SDL already converts pixels to a supported texture format for the render backend at a higher level before calling its UpdateTexture method.

Going to leave this open for now while I figure out what went wrong.

--ryan.
Comment 3 Ryan C. Gordon 2020-12-10 06:07:48 UTC
Disregard, turns out the emscripten app was accidentally mangling pixel data before handing it to SDL, and SDL's renderer was processing the incorrect data correctly.

--ryan.