Daniel J Laird wrote: > All, > > I have been comparing the performance of DirectFB 1.2.x vs 1.0.0. I have > rewritten my driver and nearly all results from df_dok run faster :-) > However stretch blitting performance has crashed and runs much slower. > I have not enabled smooth stretch blitting. > > My hardware does not support stretch blitting and as such I am using the SW > implementations in both versions. > > Has anyone else seens this? > Any clues as to the reason? > > Is the previous stretch blitting optimised more or is the new implementation > better in more circumstances but overall some tests may run slower?
There shouldn't be a difference with default options. But if you use the "thrifty-surface-buffers" the software renderer will be reading from (presumably) uncached graphics memory, after the surface buffer has been transfered during one of the blitting tests. Try "df_dok --stretch-blit" alone or "df_dok --dfb:no-hardware"... The upcoming surface task queue manager will allow cached graphics memory with explicit (and intelligent) calls to flush/invalidate caches on either one of the CPUs or GPUs based on access history. Also, by keeping finished tasks in a "history" or at least a "recycling" queue, there's a lot of potential for heuristics that would pull the allocation back or even start the transfer before the receiving side will request it again :-D -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
