Why ? Isn’t pageflipping supposed to just flip the pointers to
the pages beeing flipped ?
Yes, but if that isn’t supported, you end up with a full screen
sysRAM->VRAM blit on every flip… If you use SDL_UpdateRects(), at
least you get speed similar to what you’d get on a target that
supports hardware pageflipping.
Ok. I got the impression that doing UpdateRect() on the whole screen
was faster than SDL_Flip() on most targets, but obviously i
misunderstood =) (or maybe not, see below).
Uhm, well, if there is h/w pageflipping, SDL_Flip() call a driver
function that does little by flip some pointers around. If there isn’t,
the entire screen will have to be copied.
SDL_UpdateRects() (which works only with a software back/shadow buffer
and a single front buffer, AFAIK) always copies data, but only in the
areas you tell it to update.
I understand that performance may suffer if
SDL_Flip flips one hardware and one software surface, if it needs
to READ from the video ram to get the current front buffer, but i
don’t see why SDL should be stupid enough to do that…
It isn’t, but it’s bad enough that it’ll end up copying the whole
buffer, although you may only have changed a few percent of the
pixels. SDL can’t help it as it doesn’t have the necessary
information - but you can provide that by using SDL_UpdateRects()
instead.
So, in other words, use SDL_Flip() only when updating the whole
screen (fx. in a scrolling game), or when wanting vsync (which isn’t
supported on most targets, i know).
Something like that… Except that when you do have h/w pageflipping, you
really do want to use it, even if you’re just bouncing a tiny ball
around the screen.
(That’s why Kobo Deluxe adds it’s own, third buffer in the default
"SemiTriple" buffering mode. Every frame, it does it’s own
"UpdateRects()" on the scrolling area, and occasionally some displays, or
the radar screen, into the back buffer, and the calls SDL_Flip().)
In those cases it’s
way better to just do a SW-SW flip, and then transfer the front
buffer to VRAM. This way no performace is lost.
On the contrary, performance is lost, compared to updating only
parts of the back buffer and the performing a hardware flip.
Yep, but not if the whole screen actually is updated… The whole
screen needs to be transferred anyway.
Correct. 
So, i guess your point is that SDL doesn’t do it this way. Since
i answered that first “why” for you, here’s another: Why ? =)
Why doesn’t SDL do it this way ? IMHO the extra memory needed for
this is far less inconvenient than a broken flipping function.
Sure, but I’m talking about performance here - and unless you need
to update the whole screen every frame, using SDL_Flip() may
result in a significant performance loss if there’s no h/w
pageflipping.
Hm. So, in a scrolling game which fx. scrolls when the player is
within 20% of the left or right border, but our hero is free to kill
Evil, moving windows™ logos in the remaining 60%, it would
actually be better to avoid using SDL_Flip() at all, and use
UpdateRect() on the whole screen when scrolling.
If there’s no h/w pageflipping; yes.
If there is; no, use SDL_Flip() (and perhaps something like Kobo’s
SemiTriple buffering mode) instead, to reduce distortion, and (possibly)
gain retrace sync.
IOW, SDL_Flip() is mostly only good for attempting to vsync, which
mostly aren’t supported ? …
Kind of, but don’t rule it out - even if there are targets that can’t
implement SDL_Flip() “properly”, there are some targets (even on Linux)
which can perform h/w pageflipping, even if it’s not retracy sync’ed.
Even if it isn’t retrace sync’ed, it usually eliminates tearing, as video
cards latch new display window position only during retrace. That is,
even if you don’t get your game to sync with the refresh rate, you
can’t get tearing, as there’s no way you can flip while the CRT is
rendering the front buffer. (If flipping is properly implemented, that
is…)
It may not look like a big deal if you manage to avoid blitting 30%
of the screen area, but keep in mind that sysRAM->VRAM blitting
without busmaster DMA is THE major performance killer in 2D
rendering - and it’s the only options for some (possible the
majority) of SDL targets.
A game that runs at several hundred fps when rendering into a
sysRAM buffer can drop to 20-30 fps as soon as you try to display
it’s output. Yes, it really is that bad.
Ouch. It would be nice if SDL could tell when this is the case (ie.
if hardware page flipping and/or DMA is available), so that a
performance-wanting game could check for it and use SDL_Flip() only
in the best cases, to attempt to avoid tearing through vsync…
It can, and Kobo Deluxe makes use of it to detect whether it should use
single buffering + software shadow buffer with SDL_UpdateRects() or
"SemiTriple" buffering.
I’m not sure about checking for DMA blitting (Kobo can’t use it anyway
because of the alpha blending), but SDL should be able to tell you about
that too.
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Thursday 11 October 2001 12:33, Trick wrote:
