Gustavo wrote: > Now to Evas part: we have an outdated DirectFB which AFAIK nobody > is using or willing to maintain and we (more specifically Cedric) > have SDL almost integrated.
The directfb engine was initially written a long time ago and was never kept up with as much as other engines, it could use a re-write. I believe Freevo was using it, but not sure if that's still the case - Jason Tackaberry did some work to bring it slightly more up to date a bit back. > I know SDL is really bare bones, so overhead of it should be > minimum, however due it being bare bones I fear it not exposing > primitives we could benefit. I couldn't find any source code or > patch for SDL, so I'm not sure what they optimized. SDL as in the software-sdl engine? I think cedric tried to use more native sdl apis for optimizing some things, but as I recall he had some issues with compositing via sdl functions due to something about their handling of alpha (maybe due to evas use of pre-mul data?). > I don't know DirectFB more than reading their website some years > ago, but looking at their code and the patch provided by Intel, > ..... > ..... > > So I'm not sure on how to proceed. Would it be better to get > DirectFB in shape, use SDL or write Evas GDL engine? Maybe my > requirements can help somehow: > ... > ... 'Fixing' the directfb engine would be good regardless, but wether to use that vs. the sdl engine vs. write a new gdl one...?? Note though that this issue of 'overlays' has come up before in regards to using evas with opengl in games.. and wether or not you do go ahead and write a gdl engine, you may still face some of the common issues that were relevant to using evas in those kinds of lud 'overlays'. Basically, if your 'overlay' can be given as a display target buffer 'surface', then you'd want to draw to such native surface buffers, and that means two things: 1. An engine that can render to such a native surface buffer (rather than using the software argb buffer engine). 2. Implement evas image 'native surfaces' for the kinds of buffer surfaces you use in (1) above. Then you'd also need some support from ecore (and enhancements to the whole sub-canvas part). But for this to work best you'd definitely want to have your native surface buffer engine do as much as possible via accelerated methods (and make sure the drivers for those are good) - if you're going to have the rendering mostly via software, then for (2) you might as well just use a software buffer engine instead (you shouldn't need to get pixels out of the display target unless you're doing some very specialized gfx effects). > What's the state of DirectFB? Was it running fine one day (ie: > directfb part is okay, it just lag behind Evas api changes)? It was ok not too long ago, just behind on some things then.. check with Jason from freevo.. maybe he can be of some help there. jose. _____________________________________________________________ Click for free info on business schools, $150K/ year potential. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3l7gMtXxsPP8YHDFA1HhQEbGNPFkaYE5rax2fYZWbJMI7LPC/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel