On Fri, 26 Oct 2001, Greg Wright wrote:
> "Sottek, Matthew J" wrote:
> >
> > XV_FRAME_TYPE = XV_HOLD
> > XvShmPutImage()
> > ...
> > XvShmPutImage()
> > ...
> > XvShmPutImage()
> > XV_FRAME_TYPE = XV_FRAME
> >
> > The target of the XvShmPutImage will only change when XV_HOLD is
> > set. (Or if XvShmPutImage is called without XV_HOLD) So however
> > many XvShmPutImage()'s get called while in XV_HOLD get put in the
> > same place overwriting each other. Once I get an implementation done
> > I'll write up some clear documentation.
> >
> > -Matt
>
>
> You and Mark were right, I was still thinking they were bit fields.
>
> But, I still have a question on the above example. In a follow up
> post Mark points out that the XV_FRAME_TYPE (or whatever it ends
> up being called) is a write only atom that takes effect on the
> next put. Is that the case? If so, The above won't work right?
> Just setting XV_FRAME_TYPE to XV_FRAME will not display the last
> held frame, instead, it won't do anything until the next put which
> will have new data.
>
I wasn't expecting clients to call XV_HOLD then Put and not
display it afterwards. There seem to be two feasible implemenations:
1) XV_HOLD stays into effect until it is displayed. If a second
Put comes along before the display the new Put overrides the
first.
2) XV_HOLD gets canceled after a second put. I expect 1) is easier
to implement.
Mark.
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
