Surface.set_alpha() sets the SRCALPHA flag

Issue #341 new
gummbum NA created an issue

This may be related to bug #340.

# Windows 7, Python 2.7, pygame.1.9.2-cp27
import pygame
pygame.display.set_mode((200, 200))
surf1 = pygame.Surface((20, 20))
print('surf1 before', surf1.get_alpha(), surf1.get_flags() & pygame.SRCALPHA)

print('surf1 before', surf1.get_alpha(), surf1.get_flags() & pygame.SRCALPHA)

Comments (3)

  1. gummbum NA reporter

    Here's a workaround for anyone in the same bind, i.e. where the routine handles generic surfaces and therefore needs to inspect them in order to apply the appropriate alpha effect.

    1. save the surface alpha
    2. set the surface alpha to None
    3. test the surface for SRCALPHA
    4. if SRCALPHA, do blending for per-pixel alpha
    5. restore the surface alpha
  2. gummbum NA reporter

    Update. And this is surprising. I verified these results on Windows 7 and Raspbian. An image with an alpha layer renders in about half the time as the same image converted and with a colorkey.

    The following renders 20 images at 770 FPS:

    image = pygame.image.load('data/tomato.png').convert_alpha()

    The following renders 20 images at 380 FPS:

    image = pygame.image.load('data/tomato.png').convert_alpha()
    image = image.convert()
    image.set_colorkey(image.get_at((0, 0)))

    This did not used to be the case. The use of colorkey used to render much faster than per-pixel alpha.

    Also I notice that in the first case, when I set alpha to None it changes how the image is rendered.

    image = pygame.image.load('data/tomato.png').convert_alpha()
    image.set_alpha(None)  # this produces an opaque image

    This also did not used to be the case. It used to be that an image with an alpha layer was unaffected by set_alpha() and set_colorkey(). The alpha layer had to be stripped in order for them to have an effect. And even if this new way is intentional, the performance of doing this is still poorer than convert_alpha().

    In my opinion, this new way is badly nuanced and full of conflicts. Ideally the behavior should be reverted to what it was prior to the 1.9.2-cp. It made more sense. I would offer more, such as looking into the C, but the challenge is too much for me.

  3. René Dudfield


    would you mind pasting these in our github? I'm sorry it wasn't clear we moved.

    This way it'll be linked to you there, and additionally we can track it easier. If you don't care if it's in your name there I can just just paste them in too.

    In any case, thanks for catching this and for giving such a detailed note about it. It is indeed a tricky one.


  4. Log in to comment