On Fri, 25 Mar 2011 16:22:24 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> On Fri, 25 Mar 2011 15:29:03 +1000 David Seikel <onef...@gmail.com> > said: > > > On Mon, 21 Mar 2011 08:48:06 +0900 Carsten Haitzler (The Rasterman) > > <ras...@rasterman.com> wrote: > > > > > 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". > > > > I'll get on topic soon, just need to take a short detour. > > > > My client finally got around to actually paying for the embedded > > project, so I'm looking at the alternatives. EFL I want to use for > > sure. > > > > I know in the past you said "use X, it does everything and saves > > you a lot of pain". Except most of the pain you mentioned is > > already a solved problem with the last project, or irrelevant to > > either project. Though the pain of getting X compiled for my system > > still remains. Lots of packages, lots of dependencies. X just > > looks like more trouble than it's worth. > > > > The old project used a combination of libsvga and ncurses, I > > really want to get away from both (inherited that old project, so > > not my choice). Using plain old fb with EFL looks very attractive > > right now. > > > > Soooo, back to the topic at hand - > > > > What's the state of fb support in evas, and is it likely to be > > killed? > > it stays - software based engine. the problem isnt the raw interface > to the display system - it's ALL the rendering calls. this mail is > about reducing the engine set down to those that use either opengl OR > software to do the rendering. getting pixels to screen is a small > part of the engine and so not worth killing engines over. > Cool. I can start now with some experiments to see if EFL on top of fb will in fact work the way I think it will. Smooth fast scrolling of a long thin image using the 486 based system will be the acid test. As nice as it would be to have X on the system, it's a really big deal to compile it all, especially when fb is already there in the kernel. Adding X to what I make can be left as an exercise for some other project, it's just complete overkill for this project. Plus, way too much bloat for our requirements. The software stack on this box has to be as minimal as possible, while being very pretty. Perfect for EFL. B-) -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
