Problem with persistent scaling/shifting in RADEONDisplayVideo()

[Roland Scheidegger]

On 25.07.2008 20:09, Thomas Hilber wrote:
> But it appears that even if I supply the following parameters to
> RADEONPutImage():
> 
> src_x 0 src_y 0 drw_x 0 drw_y 0 src_w 720 src_h 576 drw_w 720 drw_h 576
> 
> the source is not copied exactly 100% to the destination. It appears if
> there still takes place a vertical shift of 1/2 pixel or even less.
> 
> As a consequence the picture jitters a little.
> 
> It tried alot to fix this and finally found a crude workaround:
> 
> If I reduce drw_h==576 from above example to drw_h==575 this implies
> a minimum scale in vertical dimension (squeeze). By this simple trick 
> I almost get a perfect picture. Only the very upper and lower borders still
> show some jitter effect.
> 
> Obviously my workaround largely compensates for the persistent and 
> unwanted 'default' image shift from above.
Not sure here what's really the problem, but it's possible the scaler
gets slightly misprogrammed in interlace mode - programming the scaler
correctly seems to be a bit tricky. Maybe you'd need to account if
you're displaying odd or even lines currently or something like that (if
you look at the displayvideo part, this one uses some of these bits).
Also, to disable scaling, maybe the RADEON_SCALER_VERT_PICK_NEAREST
would do the trick (but I don't think it really helps with your
problem). I don't think there's any public documentation for programming
the scaler, however.
That said I don't fully understand how the interlaced frames get there
really, if your source is interlaced wouldn't the source images only
have half height and you'd scale them up by a factor of 2 (e.g. you'd
pretend to do bobbing, but since your scanout is interlaced you'd
actually get back the normal interlaced picture).
(Though, IMHO interlace should have been buried along with analog
transmission - this clever 1930-ish hack just doesn't make much sense
any longer and is just cause for pain...)

Roland