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
