Re: [pygame] Bizarre(?) per-pixel alpha vs. no alpha benchmark results

["Pete Shinners" <shredwheat@mediaone.net>]

whew, ok, sy a ton of info and questions. i'll be able to
make some clarifications. first. the biggest factor of speed
when blitting will come from what type of blits the hardware
supports. you can get this info in a large structure like
object. "print pygame.display.Info()" will construct this for
us, it is easy to print and see the values:

<VideoInfo(hw = 1, wm = 1,video_mem = 31274
           blit_hw = 1, blit_hw_CC = 1, blit_hw_A = 0,
           blit_sw = 1, blit_sw_CC = 1, blit_sw_A = 0,
           bitsize  = 32, bytesize = 4,
           masks =  (16711680, 65280, 255, 0),
           shifts = (16, 8, 0, 0),
           losses =  (0, 0, 0, 8)>

probably the most informative sections are at the top. first
we see if the screen surface is at all hardware accelerated (hw),
then we can see if any types of blits are hardware accelerated.
in my example you can see just about all blits are accelerated
(sw to hw, hw to hw, plus the colorkeyed blits too) the alpha
blits are not accelerated, so they will be done in software.

i think one of the things throwing you for a loop is the fact
that SDL is not giving us a hardware display surface, unless you
ask for a fullscreen surface. this is a bug in SDL and i've just
reported. this means that anytime you create a non-fullscreen
display surface it will always be in software, no hardware accel.

the second most important thing that will always effect your
speed is making sure your surfaces have the same format. use
convert() to make your surface as fast as possible for blitting
to the display. convert_alpha() will do the same thing for
surfaces with a perpixel alpha channel.

i did some quick benchmarks with your files. i didn't see the
.TGA included, so i didn't run any tests with alpha enabled,
nonetheless, take a look at my results...

SW -> SW, no alpha, no convert:   25fps
SW -> SW, no alpha, convert   :   28fps
SW -> HW, no alpha, no convert:  122fps
HW -> HW, no alpha, convert   : 1100fps

as you can see, once we start getting into the world of
hardware acceleration, the speed starts to take off.

i'll try to address your specific questions, but even some
have me a little baffled. these questions are more "SDL specific"
since pygame is just passing your values along to the SDL
library.


> Comment: Why is p.p. Alpha blit faster in windowed modes?

anytime software blitters are required, they will always run
faster if they are working on software surfaces. software effects
working on surfaces in hardware are slower because they need to
do their work across the pci/agp bus, a lot slower than system
memory.


> Comment: Why does using double-buffering impose such a huge
> performance hit on the alpha blending and at the same time
> INCREASE the performance of the plain opaque blit?!?

i'm not exactly sure, but again i am suspect of what types
of surfaces you are really getting back from SDL. DOUBLEBUF
will only be helpful with HWSURFACE (and FULLSCREEN because 
of that SDL bug).


> Comment: Severe tearing when not using DOUBLEBUF, even 
> when the fps was way below the refresh rate as in the 
> case of the alpha blits!  Why would using HWSURFACE
> create tearing? 32-bit results analogous to 16-bit
> ones.

once you get a real HWSURFACE without DOUBLEBUF, any actions
you take will directly effect what you see on the screen. this
also makes the flip() a no-op so there is nothing to do. perhaps
it would be better if SDL's flip would just wait for a vertical
retrace before returning, but it does nothing.
so when you are working with this type of display your game will
never be synched to the monitor refresh. thus the tearing.
 

> 1. Enabling RLEACCEL made no difference for all the 
> plain opaque blits.

correct. a surface with RLEACCEL will always be doing software
blitting, since RLEACCEL is a special software SDL blitter.
it can really make a difference on colorkey and perpixel alpha
surfaces that have large sections of "on/off".


> 2. In windowed mode, HWSURFACE doesn't seem to have
> an effect even if i use a low-res mode like 800x600. 

yeah, this is that SDL bug. hopefully we can get some word 
back on that soon.


hope this helps. if your just doing a lot of straight blitting
in your app, hardware surfaces are the way to go. but if there
will be lots of fancy alpha blitting happening, you'll probably
be best with all software surfaces (unless you determine the
videocard will be able to accelerate them all).



____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org