On Sat, Feb 14, 2009 at 5:10 PM, Lenard Lindstrom
<len-l@xxxxxxxxx> wrote:
The SDL blitters are used when the destination has no SRCALPHA and colorkey or a different pixel size from the source. As I mentioned earlier, it is tricky identifying a problematic self blit. It is done by PygameSoftBlit in alphablit.c, but at that point Pygame has committed to doing the blit itself. Of course SDL_Blit could be called from PyGameSoftBlit or the address calculations -- involving resolving Rect boundaries -- can be moved to PySurface_Blit in surface.c. For the moment I just want to get it working correctly. It can be tweaked later. Besides, if the SDL blit bugs are fixed, then this patch becomes unnecessary. A search in their Bugzille didn't show any bug reports on colorkey blit problems though. I only found a one bug report on a problems blitting one part of a large surface onto another part.
Lenard
René Dudfield wrote:
Hi,
I was seeing if it's possible to use the SDL color key blitters for
the cases where they work? Since they are all mostly optimized mmx...
but maybe I'm missunderstanding what you've done.
nice work on all the blitter fix-ups by the way :)
cheers!
On Sun, Feb 15, 2009 at 7:11 AM, Lenard Lindstrom <len-l@xxxxxxxxx> wrote:
Hi René,
I'm not sure what you are asking. Pygame could be limited to only handling
the self blits when the destination has colorkey. But deciding if something
is a self blit requires some involved address calculations. Unfortunately
those are done in alphablit.c, after the decision is made whether to blit
with SDL or Pygame. If you are asking that all blits involving a destination
with colorkey be handled by Pygame, I have extended the blit routines to
handle that. The same issues apply to blanket alpha as well.
Lenard
René Dudfield wrote:
hi,
can we make it all SRCALPHA self blits done with pygame? Because I
think the SDL colorkey blits should be lots faster.
cheers.
On Sun, Feb 15, 2009 at 4:04 AM, Lenard Lindstrom <len-l@xxxxxxxxx> wrote:
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>