Extension for 2D with DRI

SDL Development
21

Mattias Engdeg?rd wrote:

               |---------------------------------> time

monitor refresh m m m m m m m m
game frame update 1 2 3 4 5 6
player sees 111111111122222333333333344444555556
object position /\ ^ /\ ^ ^

In this example, frames 1 and 3 are shown twice as long as frames 2, 4 and 5.
Imagine you have an object moving with constant speed on the screen. To
maintain the illusion of constant speed, the time points for each frame
should be the midpoint of the interval during which the frame is seen by
the player (marked by ^ and /). Of course, these have to be known in
advance when rendering a frame (in order to draw the object at the right
place), but then you must know where you are in relation to the vertical
refresh.

And even then, I’m not 100% sure that motion will be perceived as
completely smooth, since the users sees the object occupying some
positions for a longer time than others.

The thing is, we’re doing our best. Synchronizing to the monitor refresh
would mean slowing down to something like half of the refresh rate (we’d
update every other frame). So you’d suck, but you’d suck evenly. If you
update as fast as you can, of course making the game logic run on its
own clock, you sometimes have a frame that stays on screen longer, but
the object will be advance by a larger increment on the next frame to
compensate, in such a way that you barely see it.

You know what? I’m in Canada and we have 60 Hz AC current. VCRs are
synchronized at a 30 fps rate, but the movies that play on them were
made with a 24 fps sampling rate. They use frame doubling and NOBODY
cares or notice. In Europe, you only have one doubled frame per second,
but here, 25% of the frames in the movie are displayed twice! And it
looks just fine.

I was told that XFree86 queues drawing requests at retrace to the
accelerator, but for operations that are done in software, the
synchronization too bad to help (the problem I described) and/or
software PIO transfers are so slow that they take more time than the
vertical refresh allows for.

This is great news. That would imply that we could replace

 XShmPutImage(Shared XImage to Window);
 XSync();

with

XShmPutImage(Shared XImage to Pixmap);
XCopyArea(Pixmap to Window);
XSync();

and get triple-buffering at (almost) no extra charge!

Well, not exactly. You don’t have tearing/shearing, but you get a slow
framerate in exchange because you do one more copy than what is needed.
I think that with XFree86 4.0, XShmPutImage is done through the
accelerator on AGP cards (not on PCI), but I’m not sure.

The thing with PCI is the physically contiguous memory requirement. I’ll
try to find a way to get contiguous memory. :-)–
Pierre Phaneuf
Systems Exorcist

22

The thing is, we’re doing our best. Synchronizing to the monitor refresh
would mean slowing down to something like half of the refresh rate (we’d
update every other frame). So you’d suck, but you’d suck evenly.

Sucking evenly can be quite smooth, but doing well unevenly can suck.

You know what? I’m in Canada and we have 60 Hz AC current. VCRs are
synchronized at a 30 fps rate, but the movies that play on them were
made with a 24 fps sampling rate. They use frame doubling and NOBODY
cares or notice.

That is because GCD(60, 24) = 12 is relatively large, so the periods of
irregularity are easy to make short. On the other hand, conversion between
50 and 60 Hz television either requires expensive interpolation equipment,
or is done cheaply and badly by dropping/doubling frames. The difference is
not hard to see.

In Europe, you only have one doubled frame per second,

but here, 25% of the frames in the movie are displayed twice! And it
looks just fine.

No, TV-converted movies in Europe play at 25fps. Yes, they go too fast, and no,
nobody notices. One doubled frame per second would be noticed.
25% doubled frames is no problem if they are spread out uniformly, but if you
are playing a game with crisp graphics at 51.721 frames/s on a monitor at
86.343 Hz, there is no small common multiple (especially since the game frame
rate isn’t even constant!).

Well, not exactly. You don’t have tearing/shearing, but you get a slow
framerate in exchange because you do one more copy than what is needed.

Right, it won’t always be a win, but if pixmaps are located in video memory
the only extra cost is a very fast intra-vidmem blit. I just tried it on
an UltraSparc, and it was noticeable slower. Unfortunately, the tearing got
worse than before, so I guess XSun doesn’t synch to vertical refresh :frowning:

23

Mattias Engdeg?rd wrote:

No, TV-converted movies in Europe play at 25fps. Yes, they go too fast, and no,
nobody notices. One doubled frame per second would be noticed.

That means when I spend 10 years in front of my TV watching US movies
here, a person in the US had to waste 10 years 15 days and 5 hours to
consume the same amount :slight_smile:

BTW, doesn’t this faster playback impose a problem with sound timing? I
mean, shouldn’t the sound go out of sync with the movie then? Or do they
play the sound faster too???–
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right

24

That means when I spend 10 years in front of my TV watching US movies
here, a person in the US had to waste 10 years 15 days and 5 hours to
consume the same amount :slight_smile:

Uh, I get (25/24) * 10 years = 10 years, 152 days, 4 hours.
European movies play too fast as well, since they are also shot at 24fps.

BTW, doesn’t this faster playback impose a problem with sound timing? I
mean, shouldn’t the sound go out of sync with the movie then? Or do they
play the sound faster too???

The sound plays faster, in sync with the movie. Except for dubbed Hong Kong
action of course, where the lips NEVER move in sync :slight_smile:

25

I don’t really believe in this. If you can make 51 fps on a monitor
going at 80 Hz, that will be better than 40 fps. Of course, the game
logic has to compensate the time properly!

For a 3D shooter you are probably right — they show a remarkable
tolerance to low frame rates and even tearing. But for a 2D game I’m
not so sure. Consider:
Hmmm…dunno what kinda 3d shooters your playing but in my neck of the
woods we always accept speed orver image quality. Quake is always played
with all fancy graphics off so you get a constant 70fps and everything
that needs to be turned off in Quake 3 is turned off until we get a
constant 60fps

Long live the confused,
Akawaka.On Fri, 14 Apr 2000, Mattias Engdegard wrote:

Bother, said Pooh, as he deleted his message base.

26

Hmmm…dunno what kinda 3d shooters your playing but in my neck of the
woods we always accept speed orver image quality. Quake is always played
with all fancy graphics off so you get a constant 70fps and everything
that needs to be turned off in Quake 3 is turned off until we get a
constant 60fps

You no doubt know more about modern 3d shooters than I do, but tearing is
much less of a concern in Quake or Doom in an X11 window (thus without sync
to vertical refresh) than any 2D game. 2D games have much simpler geometry
and kinematics, so any tearing or deviation from rectilinear movement is
easy to spot. Marathon, an early FPS, was capped at 30fps for whatever
reason, and it was not perceived as a serious limitation.

27

Mattias Engdeg?rd wrote:

You know what? I’m in Canada and we have 60 Hz AC current. VCRs are
synchronized at a 30 fps rate, but the movies that play on them were
made with a 24 fps sampling rate. They use frame doubling and NOBODY
cares or notice.

That is because GCD(60, 24) = 12 is relatively large, so the periods of
irregularity are easy to make short. On the other hand, conversion between
50 and 60 Hz television either requires expensive interpolation equipment,
or is done cheaply and badly by dropping/doubling frames. The difference is
not hard to see.

I do not know for conversion between 50 and 60 Hz, but I know for a fact
that conversion between 24 fps film movies and North American 60 Hz
television is done by doubling frames. Yes, the “cheap and bad” method.
And the difference is hard to see! Heck, going from 24 to 30 means
that 1 out of every 4 frame is displayed twice! When I learned that, I
was amazed that such a crappy method looked so fine!

No, TV-converted movies in Europe play at 25fps. Yes, they go too fast,
and no, nobody notices.

Argh, they really play it a bit faster? Wow, for a two hour feature
movie, that mean losing almost 5 minutes! But hey, at the speed that
french people talk and the number of silent scenes they like having in
movies, I can understand people not noticing (and actually enjoying the
extra speed!)! :wink:

One doubled frame per second would be noticed. 25% doubled frames is
no problem if they are spread out uniformly, but if you are playing a
game with crisp graphics at 51.721 frames/s on a monitor at 86.343 Hz,
there is no small common multiple (especially since the game frame rate
isn’t even constant!).

The thing is, can you notice a punctual 1 fps difference when playing a
game? One frame per second? I’m not talking about times where Q3A
actually drops 5 frames on the floor, a single one! If you turn on
"cg_drawfps" and look at the counter, you’ll probably notice that it is
probably flickering between two or three numbers! And when you look at
the action, it is okay and looks pretty regular, doesn’t it?

Well, not exactly. You don’t have tearing/shearing, but you get a slow
framerate in exchange because you do one more copy than what is needed.

Right, it won’t always be a win, but if pixmaps are located in video memory
the only extra cost is a very fast intra-vidmem blit. I just tried it on
an UltraSparc, and it was noticeable slower. Unfortunately, the tearing got
worse than before, so I guess XSun doesn’t synch to vertical refresh :frowning:

So few X server actually puts pixmaps in video memory, it is a shame. If
you are lucky, system to video memory transfers are done using some fast
interface, like DMA instead of PIO. And if it uses PIO to do the
transfer and that the transfer takes longer than the vertical retrace,
then even if it is synchronized to the vertical retrace, you’ll see
artefacts.

One of the reasons the new XFree86 4.0 servers are so fast is that they
started using the video memory intelligently. Try the 500x500
pixmap-to-window benchmark in x11perf on the old and new servers, you’ll
see what I mean.–
Pierre Phaneuf
http://ludusdesign.com/

28

I do not know for conversion between 50 and 60 Hz, but I know for a fact
that conversion between 24 fps film movies and North American 60 Hz
television is done by doubling frames. Yes, the “cheap and bad” method.

Cheap but not bad. The large common divisor makes the period short.
The usual 2:3-transfer alternates between 2 and 3 half-frames per film
frame (according to the well-informed TV/video standards FAQ,
http://www.bawue.de/~agnus/FAQ_Video.text). For an analogy in computer
graphics, think of a pattern dither: if you have a fine-grained, regular
pattern, it looks like a solid colour from afar, but large, irregular
patterns are more likely to show artifacts.

The thing is, can you notice a punctual 1 fps difference when playing a
game? One frame per second?

Yes. You are more likely to notice 1 extra frame out of 24, than 12 extra
frames, one inserted every 2 frames.

[Quake example]

And when you look at
the action, it is okay and looks pretty regular, doesn’t it?

No doubt so, but I believe 3D games are more resistant to it. I will try
to construct a 2D demo where the effect can be seen, to convince myself
and any heretics :slight_smile:

And if it uses PIO to do the
transfer and that the transfer takes longer than the vertical retrace,
then even if it is synchronized to the vertical retrace, you’ll see
artefacts.

Yes, possibly even worse since the tearing will occur at the same scan line
every time. This was not what happened on the Ultra, so its blitting isn’t
synchronized.

One of the reasons the new XFree86 4.0 servers are so fast is that they
started using the video memory intelligently. Try the 500x500
pixmap-to-window benchmark in x11perf on the old and new servers, you’ll
see what I mean.

Unfortunately the only Linux box I have access to right is not supported
by XF4.0, but I understand the improvement is considerable.

29

Mattias Engdeg?rd wrote:

I do not know for conversion between 50 and 60 Hz, but I know for a fact
that conversion between 24 fps film movies and North American 60 Hz
television is done by doubling frames. Yes, the “cheap and bad” method.

Cheap but not bad. The large common divisor makes the period short.
The usual 2:3-transfer alternates between 2 and 3 half-frames per film
frame (according to the well-informed TV/video standards FAQ,
http://www.bawue.de/~agnus/FAQ_Video.text). For an analogy in computer
graphics, think of a pattern dither: if you have a fine-grained, regular
pattern, it looks like a solid colour from afar, but large, irregular
patterns are more likely to show artifacts.

Darn, the link is in german and sure looks interesting!

But I know a bit about dithering, and you might also know that some
types of dithering uses random patterns so that it looks more natural
(the regular patterns of dithering sometimes forms higher-level
artifacts, often looking like bands). Not convinced yet.

[Quake example]

And when you look at
the action, it is okay and looks pretty regular, doesn’t it?

No doubt so, but I believe 3D games are more resistant to it. I will try
to construct a 2D demo where the effect can be seen, to convince myself
and any heretics :slight_smile:

Yes, I’d be happy to see a demo! Well, actually, Quadra (our game, see
the URL at the bottom for more info) does slips duplicated frames
onces in a while in a semi-random manner, at high framerates (when you
get over 100 fps, which is the limit of the game clock, it fills up with
duplicate frames). In 8 bit PseudoColor on my P225 and with a high vsync
rate on my monitor (I have a “Professionnal Serie” ViewSonic monitor,
quite good, I recommend them very much), it happens and can’t really
tell without the framerate indicator. The main animation consist of a 2D
block that falls down the screen in a smooth manner.

And if it uses PIO to do the
transfer and that the transfer takes longer than the vertical retrace,
then even if it is synchronized to the vertical retrace, you’ll see
artefacts.

Yes, possibly even worse since the tearing will occur at the same scan line
every time. This was not what happened on the Ultra, so its blitting isn’t
synchronized.

PIO transfers are done by the CPU, and because of scheduling, the
tearing doesn’t occur at the same scan line. Doesn’t prove that the
blitting isn’t synchronized, it could still be. It should happen
"around" the same scan line, plus or minus 50 lines I’d say, with
possibly larger pathological variations once in a while.–
Pierre Phaneuf
http://ludusdesign.com/