Ville Syrjälä wrote: > On Mon, May 08, 2006 at 10:43:32PM +0200, Stefan Lucke wrote: >> 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.
I remember :) The font rendering code has been changed in between to work on its own graphics state. That saved setting up the source everytime when it's still the same font surface as before (and no other state has been used in between). >>> 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? >> 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? Does the destination's field parity influence that? But wouldn't swapping produce mispositioned (+-0.5 lines?) half pictures which combined look like NagraLite? :) -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | '------------------------------------------' _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
