Quoting Ville Syrj�l�: > On Thu, Apr 29, 2004 at 09:28:12AM +0200, Kristof Pelckmans wrote: > > Wouldn't it be nice to have these conversions in the DirectFB framework, so one > > could just have a source surface in a particular format and blit it to a > > destination surface with a different format ? > > DirectFB can generally do that but the software accel code for YUV formats > is quite incomplete. And software format conversion blits aren't very fast > with DirectFB. To make them faster we could add support for optimized > functions for each source/destination format combinations. Patches are > welcome ;)
Modularizing pixel formats in the software driver has a very high priority, especially talking about such optimized routines that could be added just by installing a module that can be built outside of the DirectFB source tree. I've already started with cutting the giant generic.c (4546 lines) into pieces being built as modules. After having extracted about four pixel formats I began wondering if it could have an impact on performance. These thoughts and especially the lack of time are the reason why I haven't down more, yet. Now it's time to continue with it. Maybe you have some ideas or thoughts, too. One important requirement that makes it difficult is full support for hybrid endian systems where the software driver has to provide on the fly endianness conversion when reading and/or writing from/to pixel buffers. That doubles the amount of functions working with one pixel buffer, e.g. loading into accumulator, and quadruples the amount of functions working with two buffers which are many. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
