On Sun, 2 Dec 2001, Billy Biggs wrote:
> Mark Vojkovich ([EMAIL PROTECTED]):
>
> > > But if it double buffered it would still need to flip-on-retrace.
> >
> > Most hardware can't not flip on retrace. I believe the MGA is one of
> > the exceptions where you can program it to flip on a particular line
> > number, the special case of, which is flipping at the retrace.
>
> Should that first sentence be 'most hardware can flip on retrace' or
> 'can't flip on retrace' ? :)
No. Most hardware cannot flip on anything but the retrace.
Not flipping on the retrace usually isn't a possibility.
>
> If the mga is so smart, I'm surprised that the XVideo driver buggers
> it up. :( Is this a bug do you think?
It's a feature. Double buffering takes twice as much video
memory and there's not much of it due to the DRI stealing it
all for 3D.
> > > So you're saying that my spinning on the client is just making the
> > > video not suck by coincidence?
> >
> > You're still getting a tear, it's just always happenning at the same
> > place so it's not so noticeable. You've essentially synced your
> > software to the retrace, but there's no way the X-server can copy the
> > data to the overlay entirely within the retrace. There's not enough
> > time. The tear is just happening a fixed time after the retrace.
>
> Um... According to my tests, the screen redraw only takes 0.064ms.
What is a "screen redraw"? I thought you were using XvShmPutImage?
That takes probably 4 or 5 ms to copy the data to framebuffer with
that driver.
> Since I'm at 85hz, that leaves pretty much the whole 11ms to copy a
> single frame to the screen. That should be plenty of time. :)
It's not doublebuffering. It is reading out the buffer while
the data is being written into it. If you don't want to shear
it has to happen during the vertical blanking. With XvShmPutImage,
that's not possible and you have to be double buffering.
Mark.
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
