You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recent updates in #2382, #2565 and #2566 have improved the speed of Surface.fill calls when using the ADD, SUBMULT, MIN and MAX blend flags. However, there’s still a fundamental issue with the fill function.
Currently, if no flags are used, the fill function simply replaces the surface pixels with the chosen color. If the color has an alpha value (and the surface is set up to support alpha), all surface pixels will adopt this alpha value, and no alpha blending will occur.
Consider this example:
importpygamescreen=pygame.display.set_mode((100, 100))
s=pygame.Surface((100, 100)).convert_alpha()
s.fill((100, 0, 100)) # all surface pixels are replaced with the solid colorprint(s.get_at((0, 0))) # outputs Color(100, 0, 100, 255)# when we fill the surface with a transparent color, # the surface pixels are replaced again, not blendeds.fill((32, 32, 32, 100))
print(s.get_at((0, 0))) # outputs Color(32, 32, 32, 100), which is incorrect
Using blit instead of fill gives different results:
importpygamescreen=pygame.display.set_mode((100, 100))
s=pygame.Surface((100, 100)).convert_alpha()
s.fill((100, 0, 100)) # surface pixels are replaced with the solid colorprint(s.get_at((0, 0))) # outputs Color(100, 0, 100, 255)s2=pygame.Surface((100, 100)).convert_alpha()
s2.fill((32, 32, 32, 100))
print(s2.get_at((0, 0))) # outputs Color(32, 32, 32, 100)s.blit(s2, (0, 0))
print(s.get_at((0, 0))) # outputs Color(73, 12, 73, 255), the expected result
In terms of the C API implementation, adding this functionality directly (meaning when the blend_flag is 0) would conflict with the current setup, as it would be impossible to distinguish between wanting to blend with alpha or overwrite the pixel completely. Not to mention it could break back-compat.
A potential solution could be to add a specific blend flag for fill like FILL_BLEND. This would allow for an easy implementation of the three possible alpha blending algorithms.
Recent updates in #2382, #2565 and #2566 have improved the speed of Surface.fill calls when using the
ADD
,SUB
MULT
,MIN
andMAX
blend flags. However, there’s still a fundamental issue with the fill function.Currently, if no flags are used, the fill function simply replaces the surface pixels with the chosen color. If the color has an alpha value (and the surface is set up to support alpha), all surface pixels will adopt this alpha value, and no alpha blending will occur.
Consider this example:
Using blit instead of fill gives different results:
In terms of the C API implementation, adding this functionality directly (meaning when the blend_flag is 0) would conflict with the current setup, as it would be impossible to distinguish between wanting to blend with alpha or overwrite the pixel completely. Not to mention it could break back-compat.
A potential solution could be to add a specific blend flag for
fill
likeFILL_BLEND
. This would allow for an easy implementation of the three possible alpha blending algorithms.So we would have something like this:
The text was updated successfully, but these errors were encountered: