On Tue, May 09, 2006 at 12:37:51AM +0200, Denis Oliver Kropp wrote: > Ville Syrjälä wrote: > > On Mon, May 08, 2006 at 10:43:32PM +0200, Stefan Lucke wrote: > >>> It also allows one to swap > >>> the fields by specifying differently aligned y-coordinates to source and > >>> destination. > >> Good idea: DSBLIT_SWAPFIELDS ? > > > > I don't think a new flag is needed. Since the current code doesn't care > > about interlaced stuff, the swap happens automatically with interleaved > > data. The implementation only get's complicated when source and/or dest > > is DSCAPS_SEPARATED or StretchBlit() is used. > > Yes, it should be automatic, while many other things like > premultiplication are not. But those things depend on the > static surface configuration. The field swapping depends > on the coordinates passed to the actual operation, or even > stored in an array for BatchBlit(). The latter one wouldn't > work with differently aligned items without automation. > > >>> 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. > >> Do you suggest just changing those values, set in matroxDoBlitTMU() ? > > > > I mean just leave TEXORG pointing to the start of the surface and ... > > Damn, that won't work :( It could work with SRCORG but not TEXORG. > > I was wondering :) But how would it work with SRCORG?
Hmm, it wouldn't :) Pardon me it was quite late... > >> That leaves the decision of using them to app developer and does > >> not change behavoiur of existing programs. > > > > Well that decision could still be left to the developer if it would only > > be activated when both source and destination are interlaced. The app > > could control DSCAPS_INTERLACED capability of the source surface. > > That should be enough. If the application created two interlaced > surfaces, it should expect proper blitting between them. > > If fields are not swapped during an unaligned blit, they show up in the > wrong order, right? Well an unaligned blit would sort of do the wrong thing every time :) either it would round the coordinates somehow or swap the fields. > Does the destination's field parity influence that? No, just the blit coordinates. > But wouldn't swapping produce mispositioned (+-0.5 lines?) > half pictures which combined look like NagraLite? :) Hmm, yes. The results might look interesting. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
