On Thu, 20 Sep 2001, Peter Surda wrote:
> On Thu, Sep 20, 2001 at 02:39:06PM -0700, Mark Vojkovich wrote:
> > Sorry, I meant XvPutStill.
> aha.
>
> > There will need to be an option for a shm completion event
> > on XvShmGetImage so the client isn't blocked while the server
> > fetches the data.
> I must confess I don't know the difference between XvPutImage and
> XvShmPutImage, but I don't mind blocking, for performance reasons
XvPutImage pushes the data through the socket. With XvShmPutImage
(only available for local clients) data is stored in shared memory
so that the server just copies it from the client's XvImage itself.
XvShmPutImage is a few times faster than XvPutImage, plus
XvShmPutImage doesn't stall the client while the transfer to the
server takes place. But because of that, the client needs an
event to know when the server is through copying it so that
the client doesn't try to modify the XvImage while the X-server is
still touching it.
> grabbing and
> encoding will has to be done in separate threads anyway. I'm an avifile
> developer and I know from experience that decoding into a buffer in one
> thread
> and displaying from the buffer in another thread allows the decoder to
> eat
> over 98% cpu even if real time spent transferring data into videocard
> takes
> over 25% (but dma does that so the drawing thread sleeps). Doing this on
> one
> thread would mean that these 25% will become wasted and additionally
> could
> cause latency problems. So my guess is that the program that grabs using
> the
> XvGetImage should grab into a buffer in one thread and a separate thread
> should encode the pictures (and another one sound) asynchronously. I
> really
> don't see a point in GetImage to be non-blocking, but perhaps I'm
> missing
> something here.
>
XShmGetImage is blocking, so maybe it's not important for XvShmGetImage
to be asynchronous. Having to send the event (and receive it)
probably just increases the latency anyhow. OK, the event is
a bad idea.
Mark.
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
