On Mon, May 08, 2006 at 10:43:32PM +0200, 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. > > > > The code is also a little strange as it tries to avoid writing to TEXORG > > because that will flush the texture cache. > > What is the disadvantage of flushing texture cache ?
Performace can suffer if it's done when not strictly needed. Once upon a time I moved the TEXORG setup from the state code to the blit function. I didn't see any performace drop then but when I later moved TEXORG setup back to the state code text rendering performance went up significantly. > > 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. I still think the automatic field handling might be good since I can't imagine anyone expecting to see separated fields on their interleaved display :) However I could live with a new blitting flag for field blitting. Field swapping I think should be automatic because otherwise odd coordinates would need rounding and if we allow both modes of operation the code would probably get even more complicated. > > 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. > Doesn't that reduce max texture width (from 2048 to 1024) for > interleaved interlaced? That already happens since texture pitch can't exceed 2048. It's just not checked by the state code. My patch fixes that. > > Maybe the whole idea of flagless field blit is too much :) > > My opinion is, when introducing new features, give them a new name. I might call it a bugfix :) > 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. > > 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. > > With my patch there are still some TODOs: > - handle separate fields They are a bit nasty since even a 2D blit has to become field aware for them. My patch should handle them but it would need some fixing so that it would not get confused about which field starts where and in which order to blit them :) -- 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
