Ville Syrjälä wrote: > 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.
That easy format addition should be possible. I thought about it the same way :) But I think we can eliminate most if not all of the switches by using function pointers. > 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. Having Genefx load the modules that are essential for the core doesn't seem good to me, too :) I think the core should load the modules. These should provide a core function pointer table including all snippets needed outside of Genefx. It does not need to be complete, but should be if the module is not an SIMD extension module. As an addition the module could provide a Genefx function pointer table. > 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 also a lot of code sharing between formats. If we use the same mechanisms for module loading as always, it should be no problem to put multiple formats into one module, sharing functions. There could be build options that control which formats go into one module and share code :) > 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? We can classify modules, BASE (loaded first) and ADDON (afterwards). Additionally, a generic priority assignment for modules could be implemented nearly as simple as it's implemented to disable certain modules. > 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. see above :) > 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. Reminds me of the idea of having the software implementation behind the same module interface as accelerated "implementations". It could eliminate the boring if/else and allow more than two sets. I've started moving modification bits to a state member dedicated to the graphics driver (mod_hw). I had in mind adding mod_sw as well and propagate bits from modified to mod_hw AND mod_sw... -- 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
