On Thu, 20 Sep 2001, Peter Surda wrote:
> 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?
Yes. By the time it gets to the driver, it doesn't matter whether
the data came through the socket or is just a pointer to the shm
segment.
>
> > 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.
For XvPut image the library has to push the data through the socket.
But once it's done that it's free to modify it's XvImage because
you've essentially copied to the X-server via the socket.
> If you have shm, you simply mark it destroyed on the client and
> when X is
> finished drawing the segment gets deallocated, right?
For the freeing, yes. Performancewise, with XvShmPutImage
you don't have to copy the data to the server. Since it's in
shared memory, the server can access the data directly. But
since both client and server share access you need the event
telling the client that the server is done reading it.
>
> 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.
>
Well, I'm not sure the ShmCompletion event is a good idea.
It's probably better that the library blocks until it receives the
reply signifying that the transfer has happened.
Mark.
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert