On Sun, 20 Mar 2011 22:34:16 -0300 Eduardo Felipe <eduardofelip...@gmail.com> said:
> 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. yeah - in trunk now map can do not just 4 points, so even with software fallback it works decently - well it works fine on pretty much everything i have tried it on - even embedded devices (software fallback). you can't get incredibly adventurous, but its more than usable. problem now is that evas can do meshes with map... and arbitrary clips... and more. anything rendered to a map should be rendered using the engine if possible. also yuv isn't handled in dfb - the colorspace code at least doesnt handle it there in the engine. expedite tests will fail for several of them. > Again, this is the latest stuff, and I've been on the 1.0 branch since > it's release. sure. > > 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. well i am open to keeping dfb engine.. if it is maintained and kept up to date. if/when we do a rewrite of the engine infra/api.. we'll worry about it then. you can always be lazy and splice in the software fallbacks from the software engine to cover new functionality if that's how you want to do it. but i really need to know that you want to and will maintain the engine (bar a rewrite). if you really do and will.. we'll keep it :) -- ------------- 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
