On Sun, 20 Mar 2011 18:27:23 -0300 Eduardo Felipe <eduardofelip...@gmail.com> said:
> On Sun, Mar 20, 2011 at 5:29 PM, Tom Hacohen <t...@stosb.com> wrote: > > On Sun, Mar 20, 2011 at 9:54 PM, Andreas Volz <li...@brachttal.net> wrote: > > > >> I was using directfb some years ago. It was a very fast way to display > >> graphics without X in Linux. May be great for embedded systems. Don't > >> you expect someone could need it? Or is the engine not that good that > >> it's usable? > > I've been using it for the last year on several versions, from > DirectFB 1.0.1 to DirectFB 1.4.3, and it works perfectly. i can bet you it doesn't work perfectly. :) it works only for a SUBSET of what evas does. map won't work. proxy won't work. yuv colorspace doesn't work. generic clip won't work. and some new things are coming in (filters) that will also not work. dfb engine has bitrotted pretty badly. current'y i consider it non-functional because it simply will not render vast amounts of things evas does and you will have rendering bugs galore. the point of evas is that you can write the thing once - on a desktop, laptop, or anywhere else, and display somewhere else using another engine.. and it works. and works right. > > If I remember correctly it's currently not faster than normal fb engine, but > > I may be wrong. :) > > Well that depends if your DirectFB implementation can do hardware > blits. I hear the praise for the fb engine but with hardware my > company develops for it is just too slow to be usable. > > My company can only use DirectFB as the hardware provides a blitter, > but no OpenGL, and the normal fb engine can't do smooth animations if > the rect that is dirty is bigger than 250 x 250px. > > I would like to be able to step up and maintain it, as I have written > patches for it in the past, but I'm afraid that I don't understand the > whole Evas codebase enough to be able to change the engine if a big > backend change happens. if you want to... first fix up all the bugs in the dfb engine that are there now. as listed above. as such currently dfb engine is broken pretty badly and it's useful to put it out of its misery. if you actually want to maintain it - that is a different matter. reducing # of enignes is simply trying to fit our work into our manpower and if every new engine feature requires you have to read up 16 gfx api's and implement it 16 times in so many engines... then we just don't have the manpower. right now we can just about support 2. software and OpenGL. pretty much because both are "universal" and thus easily accessible. even that is "significant work". if you really want to maintain the dfb engine... by all means - it's worth reconsidering, though be warned. we will re-write the engine api at some point. it's grown to be a bit of a mess over the years. but right now it's time to "reduce the work a rewrite would take" but removing engines we can't/don't want to support. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
