On Dienstag 09 Mai 2006 07:21, Stefan Lucke wrote:
> On Montag 08 Mai 2006 18:54, Ville Syrjälä wrote:
> > On Sun, May 07, 2006 at 10:52:54PM +0200, Stefan Lucke wrote:
> > >
> > > Ok, here is the latest one (done against DirectFB cvs from 2006-04-14).
> > > But I'd like to have a comment from Ville, as I count him as _the_
> > > reference of matrox programming.
> >
> > :)
> >
> > I actually experimented with something similar some time ago but I
> > didn't get the patch into a good enough shape so it was left gathering
> > dust on my HD. My approach was done without a new blitting flag. My idea
> > was that a blit should handle the fields properly without any flags.
> > I've attached the patch. I just excavated it from my source tree which
> > was a real mess so it might not even compile.
>
> I tested your patch. I applies with a few offsets and compiles clean.
> There are 2 issues:
> - I guess the restore of registers is missing. Had a similary behaviour
> when dropping register restore from my patch. I'm doing:
> scrSurface->SetBlittingFlags(DSBLIT_NOFX);
> scrSurface->StretchBlit(videoSurface, &src, &dst);
> if (OSDpresent)
> {
> scrSurface->SetBlittingFlags(DSBLIT_BLEND_ALPHACHANNEL);
> scrSurface->StretchBlit(osdSurface, &osdsrc, &osddest);
> }
> So the OSD is at double high, partly out of screen.
> - When OSD disappears there are a few strechblits of video witch
> results in half high video on TV
To be a bit more preceise in the second case:
It happens to when OSD actions start. What is in common between them:
target surface gets cleared scrSurface->Clear(0,0,0,0); .
When there is a aspect change (full - 4:3 -> downscaled - 16:9), the half
high video frame stays partly, non flickering on screen (where black
bars should be in that case).
Automagic interlaced handling would be better than an additional flag, but ..
Ville did you had a look at this, or do you expect me to fix it ?
>
> Your patch does detect interlaced source correct, without setting
> this DSCAPS_INTERLACED video shows as without patch.
>
> >
> > The code is also a little strange as it tries to avoid writing to TEXORG
> > because that will flush the texture cache. It also allows one to swap
> > the fields by specifying differently aligned y-coordinates to source and
> > destination. Unfortunately these two features also made the code do
> > wrong things. Currently it leaves *ORG registers pointing to field 0 but
> > it can start blitting from using field 1 coordinates. Now that I think
> > about it it might be best to solve the problem by not switching *ORG for
> > different fields but instead just modify the blit coordinates.
> >
> > Maybe the whole idea of flagless field blit is too much :) There are
> > certainly some unresolved issues like what to do with separated ->
> > progressive stretch blit. Also the code is getting more and more complex
> > due to all these fields and planes.
> >
> > --
> > Ville Syrjälä
> > [EMAIL PROTECTED]
> > http://www.sci.fi/~syrjala/
> >
>
> --
> Stefan Lucke
>
> _______________________________________________
> directfb-dev mailing list
> [email protected]
> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
>
>
--
Stefan Lucke
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
