> I was under the impression that GGI could support double or
> triple buffers FBs.
Right. That is possible. The pageflip.c demo shows how to do it.
> Which if I understand correctly, are used to avoid flicker and
> other bad behavior.
Yes. However one should have a fallback method, as you don't always
have doublebuffer support (because of not enough VRAM e.g.).
> So can something like this be done?
> 1. Draw lots of items to an inactive buffer
> 2. Flush when the image is complete.
> 3. On vertical retrace make the inactive buffer active.
Yes. That's the "really right" way to do it, if you can get multiple frames.
> How would this be done?
ggiSetWriteFrame(vis,inactive_frame);
ggiDrawWhatever(...);
ggiFlush(vis);
ggiWaitRayPos(...);
ggiSetDisplayFrame(vis, inactive_frame);
swap(&inactive_frame,&active_frame);
I think you get the picture.
> I am assuming that when triple buffered there is an opportunity
> to complete drawing operations for the next buffer and then move
> on to drawing the one to be used after that so the a fully
> drawn 'next' buffer is ready whenever the retrace happens.
Yes. It's basically to make use of the "spare time" while waiting for the
retrace. it is especially useful, if you have a LoD-Algorithm that will
spend extra cycles to "perfect" the image if there is enough time.
You can't do that on the buffer that is about to be displayed, as you might
need to display a half-done buffer if you run out of time.
However if you have a full frame left, all is well.
Triple-buffering is often hardware-assisted, as you will be drawing in the
third buffer while the second buffer is waiting for retrace. If you draw
too long before checking for retrace, flicker will occur.
Hardware-assistance will automatically switch frames when retrace happens
and you can later query that the change happened.
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
