Very Computer

I want my X-based application (that displays some animation) to sync
with the vertical retrace of the CRT.

So far I have tried (and considered) the following:
  1) DBE                        does not sync
  2) XF86VidMode_SetViewPort    syncs with _some_ drivers (e.g., Matrox MGA)
  3) OpenGL                     not an option for me (as my X-terminals
                                do not offer 3D-hardware)
  4) DGA_SetViewPort            seems to sync with _some_ drivers

Is there any reliable, convenient interface that offers that feature?

Thank you.

Best Regards,
Stefan

And not all displays even have either scanning or vertical retrace. Flat  
panels, for example. Some of the latter presently accept an analog TV-style
signal, but eventually this fiction will go away and these displays will
become a simple memory-mapped device, coupled to specific addresses in the
system's memory.

What you *do* want to do is use graphic double-buffering in your program.
This is the standard, robust way to make flicker-free animations that are
not platform-dependent. It is the *only* solution that will stand the test
of time.

Like this:

1. Display completed image in buffer A.
2. Write new image to buffer B.
3. When (2) is finished, switch display from buffer A to B, and start over
at (1), transposing A and B in the instructions.

Quote:> Is there any reliable, convenient interface that offers that feature?

--
Paul Lutus
www.arachnoid.com

: > I want my X-based application (that displays some animation) to sync
: > with the vertical retrace of the CRT.
: Oh, no, you don't. This would make your application terribly non-portable.
: On some machines with high scan rates, your applicaiton would not be able
: to function at all.
Yes, I do.
I want to display consistent states and I can only accomplish
that by syncing with the vertical retrace.

: And not all displays even have either scanning or vertical retrace. Flat  
: panels, for example. Some of the latter presently accept an analog TV-style
: signal, but eventually this fiction will go away and these displays will
: become a simple memory-mapped device, coupled to specific addresses in the
: system's memory.
Granted. Then I would have to insert some additional delay...
(I can use the SYNC-extension for that.)

: What you *do* want to do is use graphic double-buffering in your program.
: This is the standard, robust way to make flicker-free animations that are
: not platform-dependent. It is the *only* solution that will stand the test
: of time.
I already do that. However, flicker-free animations can still show
tearing effects (on CRTs).

: [...]
: > Is there any reliable, convenient interface that offers that feature?
: You need to rethink your approach to the problem.
So how should I do fast animations (that have high contrast)?

Regards,
Stefan

Quote:

> : And not all displays even have either scanning or vertical retrace. Flat
> : panels, for example. Some of the latter presently accept an analog
> : TV-style signal, but eventually this fiction will go away and these
> : displays will become a simple memory-mapped device, coupled to specific
> : addresses in the system's memory.
> Granted. Then I would have to insert some additional delay...
> (I can use the SYNC-extension for that.)

Quote:

> : What you *do* want to do is use graphic double-buffering in your
> : program. This is the standard, robust way to make flicker-free
> : animations that are not platform-dependent. It is the *only* solution
> : that will stand the test of time.
> I already do that. However, flicker-free animations can still show
> tearing effects (on CRTs).

> : [...]
> : > Is there any reliable, convenient interface that offers that feature?
> : You need to rethink your approach to the problem.
> So how should I do fast animations (that have high contrast)?

How do you think high-performance, fast-update graphic games produce their
results? They use double-buffering -- they create a new image off-screen,
then they show it when it is ready, seamlessly, without flicker.

--
Paul Lutus
www.arachnoid.com

: > Granted. Then I would have to insert some additional delay...
: > (I can use the SYNC-extension for that.)
: No, you do not have to introduce any delay at all. In fact, double buffering
: is overall faster than what you are proposing to do, because it always
: shows the most recent image, regardless of what display constraints exist.
It is faster. But it does not give me the output that I want.
Maybe because the animation is too fast?!

: > So how should I do fast animations (that have high contrast)?
: Use double buffering? Any graphics textbook explains this, the reasons and
: the results. Double buffering guarantees portability and the assurance that
: the most recent image is always made available to the display device.
: Double buffering can in principle provide image updates much faster than
: the display can update itself, and the image is always flicker-free. And
: the method is entirely independent of the display hardware.
Please listen to me, just for a second:
  1) You do not need to teach me what double-buffering is (or how it works).
  2) Flicker-free does not necessarily imply that the animation is free of
     tearing-effects.

: How do you think high-performance, fast-update graphic games produce their
: results? They use double-buffering -- they create a new image off-screen,
: then they show it when it is ready, seamlessly, without flicker.
Conventional animations usually have small contrast between frames.
The animations that I want to do _always_ have a high contrast.

Please have a look at the following URL
'http://www.complang.tuwien.ac.at/skral/download/eyefriendly_xfree86/'.

If you compile and run test_nosync_dbe or test_nosync_copyarea,
you will see that double-buffering alone does _not_ solve the problem
of images being teared. In fact, most (if not all) all images displayed
on the screen do not reflect a consistent state (which would be
a completely white or a completely black window --- or maybe some window
filled with some grayscale).

Regards,
Stefan

Quote:

> : > Granted. Then I would have to insert some additional delay...
> : > (I can use the SYNC-extension for that.)
> : No, you do not have to introduce any delay at all. In fact, double
> : buffering is overall faster than what you are proposing to do, because
> : it always shows the most recent image, regardless of what display
> : constraints exist.
> It is faster. But it does not give me the output that I want.
> Maybe because the animation is too fast?!

Quote:

> : > So how should I do fast animations (that have high contrast)?
> : Use double buffering? Any graphics textbook explains this, the reasons
> : and the results. Double buffering guarantees portability and the
> : assurance that the most recent image is always made available to the
> : display device. Double buffering can in principle provide image updates
> : much faster than the display can update itself, and the image is always
> : flicker-free. And the method is entirely independent of the display
> : hardware.
> Please listen to me, just for a second:
>   1) You do not need to teach me what double-buffering is (or how it
>   works).

Quote:> 2) Flicker-free does not necessarily imply that the animation is
>   free of
>      tearing-effects.

Quote:

> : How do you think high-performance, fast-update graphic games produce
> : their results? They use double-buffering -- they create a new image
> : off-screen, then they show it when it is ready, seamlessly, without
> : flicker.
> Conventional animations usually have small contrast between frames.
> The animations that I want to do _always_ have a high contrast.

--
Paul Lutus
www.arachnoid.com

Quote:> 1. Display completed image in buffer A.
> 2. Write new image to buffer B.
> 3. When (2) is finished, switch display from buffer A to B, and start over
> at (1), transposing A and B in the instructions.

Also, writing a program depending on the viewer to be using a
digital display, it seems to me, would invite the very portability
problems you are warning about.

--
Steve Martin, CPBE CBNT

Quote:> Yes,
> this is not an issue with digital flat panels; however, the majority
> of displays in existence at this point in time are the old-fashioned
> CRT-based monitors, so this is definitely an issue.

Quote:

>> 1. Display completed image in buffer A.
>> 2. Write new image to buffer B.
>> 3. When (2) is finished, switch display from buffer A to B, and start
>> over at (1), transposing A and B in the instructions.

> This is a good description of the process. However, if the "switch
> display"
> point in step (3) is not synchronized with vertical retrace, then there
> is a discontinuity in the displayed image that is under certain
> circumstances quite perceivable to the viewer.

Quote:

> Also, writing a program depending on the viewer to be using a
> digital display, it seems to me, would invite the very portability
> problems you are warning about.

If the user of a program sees artifacts from the animation, maybe the frame
repetition rate is too low. There are plenty of unavoidable effects caused
by the frame rate in various media, but the single solution is to use frame
buffering. Everything beyond that is an unavoidable artifact (like the
picket-fence effect seen in varioud contexts in movies and TV).

Even synchronizing the program's frame rate with that of the display will
not solve the classic synchronization artifact problem. It has precisely no
worthwhile purpose.

--
Paul Lutus
www.arachnoid.com

In the following, I will give a quick summary of what your
"contribution" to this thread has been so far:
  (1) Everything that was not written by you is either "nonsense"
      or "complete, total nonsense".
        => I do not think that this discussion style is acceptable.

  (2) You do not provide plausible reasons or any kind of proof to
      justify your claims. Things are the way you say, just because
      you say so.
        => Try to convince people with sound logic.
           Do not try to persuade anyone.

  (3) You do not actually _react_ to contributions by others. You could
      have tried one of the test-apps that I wrote.  They illustrate
      that double-buffering alone is _not_ enough (at least on CRTs).
        => Discussions should not be monologs.

  (4) You looked down on me, trying to teach (trivial)
      concepts like double-buffering.
        => I can safely refuse that offer. Almost having completed
           my masters degree in computer science I know about
           basic, intermediate, and advanced concepts in this field.

The reason I wrote this is not to insult you, but to get to the point
where we can have a reasonable discussion.

Best Regards,
Stefan

First, for older video cards, the hardware and/or X server probably don't
provide any means of timing operations according to the vertical trace.  That
fact alone would prevent any standardized interface (though it wouldn't
preclude an extension to do it.)

For newer video cards, double buffering in video memory will automatically be
synchronized with video output by the hardware (I'm guessing), so the X server
doesn't need to do anything for it.

Lastly, vertical refresh rates can vary by card, video mode, and user
preference.  So if, for example, you want your program to display a smooth 60
fps animation, you can't expect an even distribution of the frames on a display
that's running at 72Hz or 87Hz.  And even if you wanted to query the display's
refresh rate and adjust your program's animaion accordingly, you have
additional problems with potential lag time in communicating with the X server
(when competing with other X clients) and getting accurate scheduling from the
host operating system (whose time slices may be as coarse as 100Hz).

Good day.

--
Paul Lutus
www.arachnoid.com

I wonder if you take the time to actually read what other people write,
or if you respond even before that.  Please feel free not to respond to
any postings of mine (past, present, and future).

Cheers,
Stefan

Try acting like a scientist.

Here's an experiment:

Set up a Linux/XFree86 system with a 3DFX VooDoo3 card (I specify
this card because it is the only one that I have encountered that
I was able successfully to synchronize with the monitor's vertical
retrace period). Ensure that the system is 3D capable, either
with DRI acceleration or simply software-based with the Mesa
libraries. Load and run the classic "gears" OpenGL demo.
Please note any temp*artifacting in the displayed image.

Now, on the same system, set the environment variable
FX_GLIDE_SWAPINTERVAL to 1. Re-run the "gears" demo. Note any
temp*aliasing in the displayed image.

I have performed the above experiment and can testify *by actual
observation* that there is indeed a distinct difference in the
quality of the image.

Please note that both attempts used the same binary, of a program
that employs double-buffering.

Until you have performed this experiment and can report the
results, I feel you have no right to belittle others' posts
with such terms as "nonsense". Try speaking from experience
for a change.

By the way, for what it's worth, I have run the "gears" demo
on both a Radeon SDR and a Matrox G550 with hardware-accelerated
DRI rendering enabled, and on both cards the same temp*aliasing
is evident.

Quote:> > This is a good description of the process. However, if the "switch
> > display"
> > point in step (3) is not synchronized with vertical retrace, then there
> > is a discontinuity in the displayed image that is under certain
> > circumstances quite perceivable to the viewer.

> Nonsense.

Quote:> Complete, total nonsense, and a post that in several ways misinterprets the
> original.

Quote:> If the user of a program sees artifacts from the animation, maybe the frame
> repetition rate is too low.

Quote:> Even synchronizing the program's frame rate with that of the display will
> not solve the classic synchronization artifact problem. It has precisely no
> worthwhile purpose.

--
Steve Martin, CPBE CBNT

Ignore that guy.
That will hurt him most in the long run.

Kirth

Idiot.

--
Paul Lutus
www.arachnoid.com