Mark Vojkovich ([EMAIL PROTECTED]):

> > It's just something silly, I guess, but important for preserving the
> > spacial position of the fields.  Say you're scaling from 720x480 to
> > 1024x768.  768/480 = 1.6, so, you want to scale up each field from
> > 240 lines up to 766.4 lines.  This gives a scaling of:
> > 
> >   [top field] y=0   to y=766.4
> >   [bot field] y=1.6 to y=768
> 
> The *sources* are subpixel.  All hardware is that way.  You couldn't
> bob video otherwise.   You double the pitch and half the surface size
> and you have a single field as a source (and bottom starts a scanline
> later).  You just adjust the offset into the texture appropriately to
> get spatial alignment correct.  It's much easier for the driver to do
> than for you to do it.

  I've read this paragraph like 3 times and I still don't understand
what you mean, sorry.  I understand how doubling the pitch and halving
the surface size gives a single field as a source, no problem, but when
you scale it up you need to subpixel resize it.

  To clarify, say I'm blitting a top field from 720x480 to 1024x768:

           Top Field                       Bot Field
    source          scale to        source          scale to
  x      = 0      x      = 0      x      = 0      x      = 0
  y      = 0      y      = 0      y      = 1      y      = 1.6
  width  = 720    width  = 720    width  = 720    width  = 720
  height = 240    height = 766.4  height = 240    height = 766.4
  pitch  = 1440                   pitch  = 1440

  So, the source offsets for these fields are integers, but what I need
them scaled to is not.  Can hardware do this easily?  I'd assume you'd
have to round down from 1024x768 to something where all of these numbers
are integers, or run at 1280x960.

>   With write-only port attributes you can essentially extend the
> Xv(Shm)PutImage function by specifying additional attributes before
> the request.  An attribute such as XV_DISPLAY_FIELD could be set to
> indicate that the next Put request is to be a field.  The value would
> be 0=top, 1=bottom in MPEG fashion.  It's a one-shot thing and only
> applies to the next put.  All drivers could add this without API or
> protocol changes. 

  Yes, this would be ideal.

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

Reply via email to