After the recent BGR discussion I started thinking about making the pixelformats modular.
First I though that wouldn't it be cool if you could simply drop in a new module without recompiling DirectFB and you would get support for a completely new pixelformat (eg. using string identifiers). But then I realized that we use a lot of switch statements so the format identifiers need to be integer constants. So I scrapped that idea. Then I actually started thinking how to implement it while still using DSPF_ constants. First I thought that I'll create a CorePixelformat that will hold function pointers to the Genefx ops. But that would expose Genefx implementation details to the core which I don't like. So my latest idea is to make Genefx load the pixelformat modules and probably turn my CorePixelformat into GenefxPixelformat (mainly to get rid of the function pointer tables). Then I would need to make Genefx provide something like "bool gIsThisFormatSupported( DFBSurfacePixelFormat fmt )" so that the core can refuse to create surfaces if the appropriate pixelformat module is not loaded. I didn't start doing the module loading stuff yet but I started splitting up generic.c to format specific parts. Actually currently I have ts in parts that sometimes have more than one format to reduce code duplication (eg. ARGB1555 and RGB555 are in one file now). I'm not sure if that's the best way but the only alternatives I can think of are code duplication and small shared libraries that would hold the code shared by multiple formats. Actually as it stands I still have a few of the most common functions (Cop_to_Aop, Bop_to_Aop, and Bop_Sto_Aop) in generic.c. I suppose those should be moved somewhere too (generally they are very small so duplicating them in multiple places should not be a huge issue but if there's a better idea I'd like to hear it). I'm still not sure how the SIMD stuff should be handled in this case. Should the SIMD code be included in the format modules or should there be SIMD modules that could override some ops from other modules? That last option would then need some way to guarantee module load order or some way for the modules to specify priority. Any thoughts? There is some format specific code around the core as well (transfer_buffer(), dfb_surface_buffer_dump(), write_argb_span() at least). Not sure what (if anything) we should do with those. Another modularization we could is to turn generic.c itself into a module. The API to the sofware driver is well defined AFAICS so it should be rather simple to do. The generic_dummy "rasterizer" could be another module then. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
