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 delay now anyhow due to the overlay
> > not going into effect until the retrace on most hardware.  It
> > introduces a larger lag between overlay and image when moving windows
> > which isn't going to be a big deal.  You can't do this for blitted
> > video though.  The cliplist is stale by the time you display.  Not a
> > problem though since blitted video are merely fallbacks.
> 
>   So, this breaks when we're paused or showing a still and you move the
> image around.  Ugh.  Are you sure this can't be handled in the hardware
> without the client having to do another put?  Or do you expect the
> client to re-put whenever it moves (which it has to now anyways)?

   It's up to the driver.  The driver can have Xv track window 
positions.  That's what the RePut functions in the Xv->driver
interface are for.  But using this means that you always have
to copy all the data to offscreen and not just the part that
is displayed because different parts may be visible when 
you move the window around.  That makes display in Xinerama prohibitory 
which is why I never use that interface in any of my drivers.
In Xinerama, each card only copies the part it is displaying
rather than copying the whole image.  That, of course, means you
can't continue to display when the window moves because you 
usually need data you haven't copied.

   To ensure that clients work with all implementations they
should Put after window configure events.

> 
> > > The XV_FRAME_TYPE will default to 0x3 (XV_FRAME) which means that
> > > apps using Xv without knowledge of this will just get a flip when
> > > they do an XvShmPutImage.
> 
>   Matt you rock my world.  Just reset this back to 0x3 when any client
> releases the port. :)

   The driver doesn't see port releases.  This would have to be a
write-only attribute that applies to the next Put in the case of
HOLD, or to whatever valid data the driver still has in offscreen
memory (if it exists) for the display.


                        Mark.

_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Reply via email to