my votes:
improve SDL blit performance
- Auto-manage software back buffer surface for better
performance on fullscreen hardware blits
That is, integrated “SemiTriple” buffering? Yeah, it would be handy
not having to create a shadow surface manually to get a s/w rendering
surface in combination with a page flipped h/w double buffer display.
However, though that would be trivial to implement, and would help in
some cases, it’s hard to figure out automatically when to use it.
On a backend, such as DirectDraw, where some blits (opaque and
colorkey, AFAIK) are h/w accelerated whereas others (alpha) are not,
it’s not as simple as one solution being faster than the other. It
depends entirely on what the application is doing.
Dropping all h/w acceleration just to deal with a small alpha
blended player sprite would result in a major performance drop on
DirectDraw, for example. Although alpha blitting to a h/w surface is
extremely expensive in itself, the full h/w acceleration you get for
other blits may be more than enough to make up for it in some
applications.
And if the application isn’t doing any alpha blending at all, there is
clearly no point in using a s/w shadow surface - especially not
without an extremely efficient dirty rect system, or constant full
screen scrolling.
- Mechanism to handle dirty rectangles within SDL
That would be handy too, but I don’t think there is such a thing as a
fully generic dirty rect management algorithm that works well in all
situations. It’s of course possible to come up with something that’s
very efficient in terms of avoiding to update unchanged areas, but
any alorithm like that is bound to have (at least) three issues:
1) It's going to burn quite a few cycles, merging rects,
calculating intersections, adjusting microtiles or whatever.
2) It's either going to generate lots of rectangles, or it'll
update lots of unchanged pixels in some situations. (The
number of rectangles may matter a lot to some backends.)
3) It's a total waste for full screen scrollers and other
applications that don't need automatic dirty rects. In
fact, it may even slow things down by getting in the way.
Right now its not “simple” to do well performing 2D in
SDL. Would be nice to free us of these complex chores.
Good point, but then again, it’s rarely simple to do anything fast.
The most effective optimizations are about exploiting the fact that
most applications need to deal only with a few specal cases.
Optimizing for the general case is about the hardest thing you can
do, if at all possible.
Well, there is one way to get “good performance” even in the general
case, though it’s not really about optimization at all: Full h/w
acceleration and just repainting the whole screen every frame. On any
reasonably current hardware, that’s fast, simple and handles pretty
much anything without side effects.
Without other side effects than that “Requires hardware accelerated
OpenGL, Direct3D or DirectFB” part, that is…
I think the stuff you mention is best done in add-on libs, or perhaps
in optional plugins of some form. It would be handy to be able to
plug such functionality in in between the SDL API and the backends,
but it’s not platform specific stuff, so it doesn’t really belong
in SDL at all, I guess. You need some info about the current video
subsystem set up, but that’s about it. You need a lot more info from
the application than from SDL to do a good job.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Saturday 26 February 2005 16.16, Jason Robertson wrote:
