On Thu, Sep 20, 2001 at 04:27:26PM -0700, Mark Vojkovich wrote:
> 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.
I get it now. It seems that I've been using the Shm version only without
knowing it. It looks like there is only one PutImage function in the driver
and the shm/socket ones are defined in X libraries, do I guess it right?
> XvShmPutImage is a few times faster than XvPutImage, plus
> XvShmPutImage doesn't stall the client while the transfer to the
> server takes place.
I C. I probably won't implement a XvGetImage in X then, only XvShmGetImage. If
someone really needs it I won't stop him/her from adding it of course, I just
don't need it and won't do it, at least not until I'm able to grab videos in a
usable way <g>.
> 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.
Now I think I understand, it's the transfer over socket that has to be waited
for. If you have shm, you simply mark it destroyed on the client and when X is
finished drawing the segment gets deallocated, right?
So no non-blocking then. Or I'll simply try to mimic a combination of
X[Shm]GetImage and Xv[Shm]PutImage to make the new function[s] fit into the
framework.
> Mark.
Bye,
Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023
--
They called their place of existence the "Universe", not the
"Great Programmer/Universe".
PGP signature
