[SDL] Re: extension for 2D with DRI
f91-men at nada.kth.se
Fri Apr 14 07:53:20 PDT 2000
>The net result is higher framerates: who doesn't want that? :-)
Nobody needs higher framerates than required for the recorded video sequence,
nor higher than vertical frequency of your monitor. But if there is a lot
of computation going on, you are right.
>> > The right thing is this: those modern boards usually support a "wait for
>> > vertical retrace" flag on their command, which will let the *board* do
>> > all the waiting.
>> Unless your game is of the type "blit an entire screenful each frame",
>> perhaps playing a movie.
>No problem with that. Just tag the blit command with the "wait for
>retrace" flag, issue it and start uncompressing the next frame.
Sure, this is the principle behind triple buffering: assuming you own the
CPU, decouple the screen refresh from the frame generation. But you may
not have that luxury.
Even if you can maintain a CPU monopoly, I can imagine situations
where it is better to produce 40 than 51 frames/s when your monitor
refreshes at 80Hz. First-person shooters are remarkably immune to this,
but other games could produce temporal aliasing problems.
>There is a big problem with any kind of userland "wait for retrace"
>scheme. If it is polling, the app might get preempted and miss the exact
>moment of the retrace, at best getting it late (perharps *too* late) and
>at worst losing it completely.
I didn't mean to let polling or blocking trigger the screen refresh;
the hardware is best suited for that (either by page flipping or by
issuing queued drawing requests at retrace). But that is not sufficient
if you want to play something at a fixed fraction of the monitor frequency.
I'm painfully aware of tearing effects from the lack of synchronization
in X11, and I really wish there was a good standard way around it.
Too bad many platforms have no usable implementation of the double-buffer
More information about the SDL