Sottek, Matthew J wrote:
Here is the proposal again, if there are on complaints I'll
implement it this way.
#define XV_HOLD 0x0
#define XV_TOP_FIELD0x1
#define XV_BOTTOM_FIELD 0x2
#define XV_FRAME(XV_TOP_FIELD | XV_BOTTOM_FIELD)
Just to clarify, the default atom
Sottek, Matthew J wrote:
Here is the proposal again, if there are on complaints I'll
implement it this way.
#define XV_HOLD 0x0
#define XV_TOP_FIELD0x1
#define XV_BOTTOM_FIELD 0x2
#define XV_FRAME(XV_TOP_FIELD | XV_BOTTOM_FIELD)
Just to clarify, the default atom
Sottek, Matthew J wrote:
Sottek, Matthew J wrote:
Here is the proposal again, if there are on complaints I'll
implement it this way.
#define XV_HOLD 0x0
#define XV_TOP_FIELD0x1
#define XV_BOTTOM_FIELD 0x2
#define XV_FRAME(XV_TOP_FIELD | XV_BOTTOM_FIELD)
On Fri, 26 Oct 2001, Greg Wright wrote:
Sottek, Matthew J wrote:
Sottek, Matthew J wrote:
Here is the proposal again, if there are on complaints I'll
implement it this way.
#define XV_HOLD 0x0
#define XV_TOP_FIELD0x1
#define XV_BOTTOM_FIELD 0x2
#define
On Fri, 26 Oct 2001, Sottek, Matthew J wrote:
Sottek, Matthew J wrote:
Here is the proposal again, if there are on complaints I'll
implement it this way.
#define XV_HOLD 0x0
#define XV_TOP_FIELD0x1
#define XV_BOTTOM_FIELD 0x2
#define XV_FRAME(XV_TOP_FIELD
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
On Fri, 26 Oct 2001, Sottek, Matthew J wrote:
If I blt a frame with the XV_FRAME_TYPE atom set to XV_FRAME|XV_HOLD,
and then, sometime later, I set the atom to XV_FRAME, what kind of
latency would I be looking at before that held buffer would show up?
Is setting atoms a synchronous call?
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
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
On Fri, 26 Oct 2001, Sottek, Matthew J wrote:
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
On Wed, 24 Oct 2001, Billy Biggs wrote:
Note that this introduces some slight uncertainty in the display since
the overlay might not correspond to the window location when it comes
time to actually display. But that's not going to be a big deal since
the times are short and you get a
On Thu, 25 Oct 2001, Sottek, Matthew J wrote:
Ok, I slightly modified the idea to take care of this too. I must
say, I really really like this one.
#define XV_TOP_FIELD 0x01
#define XV_BOTTOM_FIELD 0x02
#define XV_FRAME (XV_TOP_FIELD | XV_BOTTOM_FIELD)
#define XV_HOLD
In light of ReputImage(), which I was unaware of. I think the first
proposal was best. I can make ReputImage() work without copying all
the data all the time.
Rather than copy the visible part of the XvImage to the offscreen
memory starting as the top left of the offscreen buffer, I'll copy
Duuudes... :)
I think Matt's idea is AWESOME.. Absolutely gorgeous. Makes me
almost cry.
I don't see how that is different that just doing two
XvShmPutImage's now and doubling the pitch and vertical scaling.
Slight difference in that the client can't bias the top down a quarter
14 matches
Mail list logo
