Well, it turns out Pygame passes colorkey target surface blits to SDL. So it
is SDL that is failing to handle self blits properly. However, I now have
Pygame blits working correctly, and they can replace the faulty SDL blits as
well. So as an interim solution, until SDL is fixed (*), all SRCALPHA
destination surface blits will be handled by Pygame. Now to verify the
Pygame blit code.
Lenard
(*) There is activity in the SDL SVN trunk so it may already be fixed.
Lenard Lindstrom wrote:
Hi Brian,
Brian Fisher wrote:
[snip]
My point is, the reason why I advocated raising an exception are gone
(i.e. the windows crashing is fixed), so I personally think that should be
off the table.
True enough. This is in the domain of Pygame, so we can actually do
something about it.
I'd say making the blit work as expected with a special case would be
great.
It will be more than just the colorkey blit that need special casing. I
recently added ten new blit loops to handle blend blits to 24 bit surfaces.
None of them are special cased. I am hoping the solution is as simple as
adjusting some pointers and stride values. Having a duplicate of every blit
routine in alphablit.c would be too cumbersome in my opinion.
[snip]
On Fri, Feb 13, 2009 at 1:14 PM, Lenard Lindstrom <len-l@xxxxxxxxx
<mailto:len-l@xxxxxxxxx>> wrote:
Hi everyone,
While checking out Mozilla bug 19 (*) I found that blitting a
surface with colorkey to itself causes repetition of the source
image. I have attached an example. This is a known problem with
copy algorithms. SDL blits have special code to handle it.
Pygame's blits do not. The concerns over self blits were discussed
in the bug 19 related thread (**), but I could find no conclusion
as to whether to support it or raise an exception and provide
explicit scroll routines instead. Pygame has many special case
blit loops to be considered.
Lenard
(*) http://pygame.motherhamster.org/bugzilla/show_bug.cgi?id=19
(**)
http://thread.gmane.org/gmane.comp.python.pygame/15390/focus=15407
--
Lenard Lindstrom
<len-l@xxxxxxxxx>