On Sun, Mar 20, 2011 at 8:48 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > 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.
You are probably correct. I haven't tried proxy as I'm currently on the 1.0 branch but the last time I used map (before 1.0) with edje it worked, although via fallback to software and too slow to be useful. Again, this is the latest stuff, and I've been on the 1.0 branch since it's release. > 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. Aside from map, where I haven't tested it through, I see no rendering bugs at all. We have a patch that adds screen dump code to directfb backend to compare the it's rendering with the software rendering (as it used to have diferences) and in 1.0 they are identical. Can't complain about that. > 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. That's precisely what I was saying. I'm not up for the challenge of rewriting it from scratch, should the API change, and there are some things that simply won't fit (DirectFB is no good for 3D, and map stuff will always be via software when using it). But this is your project so do as you must. I'm happy to stay in 1.0 as it suits my needs. > -- > ------------- 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
