> The only problem with that it it doesn't matter. Frame buffering always
> minimizes artifacts, and those artifacts that remain are unavoidable
> regardless of approach.
Paul, I'm going to suggest that you follow some of your own advice,
something I've seen you suggest to others in some of your other posts.
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
> > 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.
I have offered experimental evidence above to substantiate my statement.
Please offer evidence to substantiate your rude repudiation.
Quote:> Complete, total nonsense, and a post that in several ways misinterprets the
That's certainly possible. I've been wrong before, as I'm sure you have.
Quote:> If the user of a program sees artifacts from the animation, maybe the frame
> repetition rate is too low.
On my current system, "gears" (on the above-mentioned Matrox) runs at
a frame refresh rate of approximately 500 frames per second as reported
by the program. My monitor refresh rate is 60.0 frames per second as
reported by the XFree86 startup log. The frame rate of the program is
obviously not "too low". The software can keep up with the display just
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.
Per the above-described experiment, it certainly does address at
least some display artifacts.
Steve Martin, CPBE CBNT