Accessing pixels of RLE surface with alpha after blitting causes color key to leak

[marcin-serwin]

Environment:

If possible, please include the output of pygame.print_debug_info() from your program in your bug report. It looks something
like this:

pygame-ce 2.5.6 (SDL 2.32.56, Python 3.13.8)
Platform:		Linux-6.17.7-x86_64-with-glibc2.40
System:			Linux
System Version:		#1-NixOS SMP PREEMPT_DYNAMIC Sun Nov  2 13:18:05 UTC 2025
Processor:			SSE2: Yes	AVX2: Yes	NEON: No
Architecture:		Bits: 64bit	Linkage: ELF

Python:			CPython 3.13.8 (main, Oct  7 2025, 12:01:51) [GCC 14.3.0]
GIL Enabled:		True
pygame version:		2.5.6
SDL versions:		Linked: 2.32.56	Compiled: 2.32.56
SDL Mixer versions:	Linked: 2.8.1	Compiled: 2.8.1
SDL Font versions:	Linked: 2.24.0	Compiled: 2.24.0
SDL Image versions:	Linked: 2.8.8	Compiled: 2.8.8
Freetype versions:	Linked: 2.13.3	Compiled: 2.13.3

Display Driver:		Display Not Initialized
Mixer Driver:		Mixer Not Initialized

I've also tested with SDL 2.30.6 and sdl2-compat 2.30.58 and the results are consistent.

Current behavior:

If you have a surface with alpha, color key, and RLE acceleration then after blitting and accessing its pixels the color becomes visible.

Expected behavior:

Blitting and accessing RLE surfaces should not change their pixels.

Steps to reproduce:

1. Run the code below.
2. Look at the produced test.png

The image will be reddish. If you either disable RLEACCEL, comment out blit or get_at then the image is white.

Test code

import pygame

surf = pygame.Surface((100, 100))
surf.fill((255, 255, 255))
surf.set_colorkey((128, 0, 0))

surf.set_alpha(90, pygame.RLEACCEL)

dest_surf = pygame.Surface((100, 100))
dest_surf.blit(surf, (0, 0))

surf.get_at((50, 50))

pygame.image.save(surf, "test.png")

[ankith26]

This is truly one of the most weird and obscure bugs I've seen in a long time! I can confirm the issue by running your reproducer locally.
The issue is sensitive to all 5 things (colorkey, alpha, rle, blit, get_at) AND the order in which it is done. I tried removing lines and swapping lines and everytime the issue was fixed.

Some more observations

• The colorkey and alpha value together seem to somehow dictate the color get_at returns, when it clearly shouldn't.
• Calling get_at multiple times seems to return different values everytime till it settles at the value provided as the colorkey (again, for completely obscure reasons).
• This is definitely not a bug on the pygame-ce side. I wrote a minimal C reproducer with SDL+SDL_image that closely follows the given code, and I can reproduce the same issue with it too

// Compile this code with:
// gcc rle_example.c -o rle_example `sdl2-config --cflags --libs` -lSDL2_image
#include <SDL2/SDL.h>
#include <SDL2/SDL_image.h>
#include <stdio.h>
#include <stdbool.h>

void read_pixel_rgb(SDL_Surface *surf, int x, int y, Uint8 *r, Uint8 *g, Uint8 *b)
{

    Uint32 pixel;
    if (SDL_MUSTLOCK(surf))
    {
        SDL_LockSurface(surf);
    }
    Uint8 *p = (Uint8 *)surf->pixels + x * surf->pitch + y * surf->format->BytesPerPixel;
    switch (surf->format->BytesPerPixel)
    {
    case 1:
        pixel = *p;
        break;
    case 2:
        pixel = *(Uint16 *)p;
        break;
    case 3:
        if (SDL_BYTEORDER == SDL_BIG_ENDIAN)
            pixel = p[0] << 16 | p[1] << 8 | p[2];
        else
            pixel = p[0] | p[1] << 8 | p[2] << 16;
        break;
    case 4:
        pixel = *(Uint32 *)p;
        break;
    default:
        pixel = 0;
        break;
    }
    if (SDL_MUSTLOCK(surf))
    {
        SDL_UnlockSurface(surf);
    }

    SDL_GetRGB(pixel, surf->format, r, g, b);
}

int main(void)
{
    if (SDL_Init(SDL_INIT_VIDEO) != 0)
    {
        fprintf(stderr, "SDL_Init: %s\n", SDL_GetError());
        return 1;
    }

    SDL_Surface *surf = SDL_CreateRGBSurfaceWithFormat(0, 100, 100, 32, SDL_PIXELFORMAT_XRGB8888);
    if (!surf)
    {
        fprintf(stderr, "SDL_CreateRGBSurfaceWithFormat: %s\n", SDL_GetError());
        SDL_Quit();
        return 1;
    }
    if (SDL_FillRect(surf, NULL, SDL_MapRGB(surf->format, 255, 255, 255)) != 0)
    {
        fprintf(stderr, "SDL_FillRect: %s\n", SDL_GetError());
    }

    if (SDL_SetColorKey(surf, SDL_TRUE, SDL_MapRGB(surf->format, 128, 0, 0)) != 0)
    {
        fprintf(stderr, "SDL_SetColorKey: %s\n", SDL_GetError());
    }

    if (SDL_SetSurfaceRLE(surf, 1) != 0)
    {
        fprintf(stderr, "SDL_SetSurfaceRLE: %s\n", SDL_GetError());
    }
    if (SDL_SetSurfaceAlphaMod(surf, 90) != 0)
    {
        fprintf(stderr, "SDL_SetSurfaceAlphaMod: %s\n", SDL_GetError());
    }

    SDL_Surface *dest_surf = SDL_CreateRGBSurfaceWithFormat(0, 100, 100, 32, SDL_PIXELFORMAT_XRGB8888);
    if (!dest_surf)
    {
        fprintf(stderr, "SDL_CreateRGBSurfaceWithFormat (dest): %s\n", SDL_GetError());
    }
    else
    {
        if (SDL_BlitSurface(surf, NULL, dest_surf, NULL) != 0)
        {
            fprintf(stderr, "SDL_BlitSurface: %s\n", SDL_GetError());
        }
    }

    Uint8 r, g, b;
    read_pixel_rgb(surf, 50, 50, &r, &g, &b);
    printf("Pixel (50,50): R=%u G=%u B=%u\n", r, g, b);

    if (IMG_SavePNG(surf, "test.png") != 0)
    {
        fprintf(stderr, "IMG_SavePNG: %s\n", IMG_GetError());
    }
    else
    {
        puts("Saved test.png");
    }

    SDL_FreeSurface(surf);
    if (dest_surf)
        SDL_FreeSurface(dest_surf);

    SDL_Quit();
    return 0;
}

[marcin-serwin]

Thank you for the C reproducer. I've simplified and checked that it still applies to SDL3, and opened libsdl-org/SDL#14424.

[marcin-serwin]

Fixed upstream.

[oddbookworm]

I want to reopen this until we can determine if this is something we can fix in our SDL2 code

[ankith26]

I think the only thing we can do is request SDL to backport it to SDL2. This issue looks too involved to fix with hacks on our side.

[marcin-serwin]

FYI, this issue doesn't occur with sdl2-compat + SDL3 from main so in my opinion backporting to SDL2 is not critical.

[oddbookworm]

FYI, this issue doesn't occur with sdl2-compat + SDL3 from main so in my opinion backporting to SDL2 is not critical.

That would blow our wheels up even more, so we probably won't distribute wheels with that build. We also don't use SDL's main branch, we only use release versions