Enlightenment version 16 was one of most configurable window managers back in late nineties (and still is). For the next version however Rasterman and friends decided to create a complete desktop shell instead of just a simple window manager. Enlighenment version 17 is therefore based on a set of graphical libraries which can used for other applications as well. But do we need another set of libraries when QT and GTK+ are already mature and stable? Depending on your needs, you might find that using the Enlightenment libraries is truly an enlightening experience!
The need for speed
GTK+ 3.0 is now being released. Great news for Gnome 3! On the other hand Nokia partners with Microsoft and the some clouds have been forming over QT. Among these big headlines you might have missed a smaller one. EFL releases 1.0! After almost a decade of development EFL get a stable API. But is this important? Why should you care?
Well if you are developing native applications for your 8-core machine with infinite memory then EFL might not seem something important to you. If however you are into embedded devices (think 8-16 MBs of RAM and simple processors) then EFL might be the best thing since sliced bread. It all comes down to speed. EFL are truly optimized for speed!
Other toolkits have usually feature based development milestones. What widgets do our users need? How are we going to support this device. Speed and performance is an afterthought. Other times the usual answer is that performance will improve with time as more and more devices get hardware accellerated graphics. But EFL is a different beast. Speed and performance improvements are a constant problem. Supporting low-end devices is a bigger success than creating another tree widget for example.
The beauty of this comes from the fact that EFL does NOT need hardware accellerated support! Although it will take advantage of it (if found) it is not a strict requirement. The reason for this is the EFL canvas (named Evas) is a lot smarter that your average QT or GTK+ canvas. Instead of blindly rendering pixels and then forgetting about them, it actually keeps track of what is shown at the screen at any given time. Then it can calculated only the parts that have changed and do not render the rest. For embedded devices this is a huge performance boost. The trick is known for a long time but it is usually found in game engines instead of application toolkits. The programmer is also completely un-aware of this.
This allows essentially for Flash like graphics (by the way flash is based on hardware accelleration as well) and animations on platforms with minimal hardware (even below smart phones). At the same time EFL provides everything you need for animations (e.g. tweening, events, the graphic loop) so the programming layer is easily understandable and usable without requiring specific knowledge on the inner workings of the canvas.
Memory footprint
A welll known rule of software engineering is the memory/ram tradeoff. You can make things faster by using more memory. EFL does not fall into this trap. In the age of gigantic libraries with several dependencies EFL is surprisingly spartan. While other libraries come in several MBs, EFL libraries are measured in kilobytes. This allows for easy installation on barebone embedded systems where QT or GTK+ might have trouble.
Low memory usage also translated into better battery life. More and more consumers demand longer periods of device operation. Cellphones and tablet are the prime example for this need. Smart usage of battery life is something that is not always given high importance in graphical libraries.
Another point to consider is also the modularity of EFL. The list might seem daunting at first sight but if you really think about it is fits perfectly in the lego like dream of software blocks. You take only what you need.
Need just the canvas and nothing else? You got it! You want a toolkit like experience? Add elementary into the mix. No need for dbus? Dump the e_dbus library. Great power is given to you on what goes onto the device. While other graphical libraries are just talking about modularization or trying to present “lite” versions of their core product, EFL is a bucket of components. Do you prefer barebones development instead of the kitchen sink approach? EFL is there for you.
Get the full package
While most other libraries for embedded systems are isolated (I/O libraries OR graphics OR networks) EFL provides you with the full toolset (if that is what you want).
- Data structures (eina)
- Themes and UI (edje)
- Canvas (evas)
- Network, SSL/gnutls, main loop,event handlers, idlers, fd management, timers (ecore)
- Architecture independent serialization (eet)
- Freedesktop standards (efreet)
- widget Toolkit (elementary)
No need to start gathering external libraries in order to create your application. All libraries can of course fully integrate with minimal hassle.
Eye candy
Most toolkits have theme support. However by “theme support” they usually mean different colours on existing components. EFL has built-in support for themes that define the whole of UI and not just colours. With the obviously split from application logic (C code) to themes (Edje files), working with a GUI designer has never been easier. Mockups from graphical tools (e.g Inkspace/gimp/Adobe suite) can be easily converted to impressive applications on the spot.
Enlightenment has a long tradition on eye candy and impressive graphics. With EFL your imagination is not limited by toolkit constraints. Themes can completely change the look of an application to something completely different. Custom UI development for embedded devices is now possible without resorting to expensive solutions or specialized architecture-speficic hacks.
Production ready
The 1.0 version just marks a stable API. It does not reflect the actual maturity of the libraries. Most open-source projects are expected to be alpha-quality in pre-1.0 version. EFL however is being used in production long before that. There are several examples (even from commercial companies) where EFL is used for production quality products.
EFL has successfully run on
- set top boxes
- game systems
- mobile phones
- Playstation 3
- fridges, printers e.t.c
Of course desktops and laptops can also use EFL.
About the author
Kapelonis Kostis is a software engineer. With the release of EFL he truly believes that hell froze ever. However he has already switched to Cairo for his graphic needs. He hopes that EFL will get the attention they deserve even at this point in time.
…pigs are flying and Duke Nukem Forever is coming out!
http://www.zupidoo.com/games/duke-nukem-forever
Well, it’s not actually e17 that’s at 1.0 though.
Heck, people say Nokia took their time with Meego? That’s amateur hour compared to e17
Ha! Good point.
I actually thought of that when I wrote my post… but I figured it would still be amusing.
I’m still waiting for a 1.0 release of GNU Hurd.
http://i163.photobucket.com/albums/t315/TheGZeus/terrible/motivate/…
I think Edje is absolutely amazing and doesn’t have it’s deserved attention.
Running enlightenment on Windows might make it it less intimidating for apple users.
That is if enlightenment can make it real, real easy:-)
The beauty of this comes from the fact that EFL does NOT need hardware accellerated support! Although it will take advantage of it (if found) it is not a strict requirement.
Do GTK+ and Qt require hardware acceleration?
The reason for this is the EFL canvas (named Evas) is a lot smarter that your average QT or GTK+ canvas. Instead of blindly rendering pixels and then forgetting about them, it actually keeps track of what is shown at the screen at any given time. Then it can calculated only the parts that have changed and do not render the rest.
Don’t GTK+ and Qt also support XDAMAGE?
Perhaps the difference is:
The programmer is also completely un-aware of this.
More elaboration is in order on how EFL is unique.
+1
rasterman has been said to be an awesome programmer doing wonders but I don’t think any post gdi32 graphic toolkit used today lacks damage/dirty information (gdi32 has at least some form of it). Java Swing has it, irrc I used an option in kde4 to monitor the redraw regions .. Any experienced dev can confirm that ?
No, except if you want some effects (3D/fast scrolling/physics). EFL provides those effects without hardware acceleration.
Yeah, but wouldn’t providing those effects without hardware acceleration kill your battery life, which was a main selling point of EFL?
I don’t know (evaluating the energetic cost of code is difficult: what architecture, how you compile, what you enable and disable, etc.). Mobile devices ship more and more with powerful GPUs, anyway, nowadays; it is just more efficient. But if you just can’t have a (good) GPU, EFL offers a way to still get what you want.
Great overview! But I think the writer loves exclamation points! Alot!
Define “speed”.
We’ve tried running E17 (via Arch Linux I believe) on our diskless machines (about a month ago), and while things are smooth, it’s not speedy. And it comes at a *very* heavy price, using up most of the 1 GB of RAM and 90% CPU with just the desktop loaded with an animated wallpaper.
Disabling the animated wallpaper drops CPU usage a bit, but it’s still over 80% when moving windows around or switching windows.
It sure looks pretty, though, with smooth animations and no tearing or anything like that. But it’s definitely not “speedy”, nor efficient.
This is on a 2.0 GHz AMD Sempron CPU with nVidia 6100 graphics onboard, and the binary nvidia driver.
GNOME 2.x, KDE 3.x, and even KDE 4.x are more efficient (10-20% CPU, 100-200 MB RAM) and nicer to use, on the same hardware. (One of the nice things about diskless clients is that switching OSes is a simple reboot away.)
A big irritation was that they had no support for wireframe resizing or moving. That was a deal killer for me (still as of 6 months ago), especially with some graphics intense applications which don’t have a friendly resize behavior.
E17 might not be speedy (for you), but that doesn’t mean the EFL aren’t.
Edited 2011-02-16 04:09 UTC
I really can’t tell what’s wrong with your setup but on Kubuntu 10.10 my CPU usage with E17 is close to 0% most of the time. That’s with the default theme (it has some system monitors), chromium and an xterm running. This is one a 5+ year old laptop at 1.3 ghz with crummy Intel 855GM video.
So yeah, I’d say it’s pretty damn smooth and speedy. Although it would be nice if the default theme wasnt so washed out with white that you can’t see anything of it.
Edited 2011-02-16 04:09 UTC
Ill preface I appreciate the arch devs for packaging pre release software. Generally my experience with packaged e17 & efl has been shaky at best. For arch using repo package my cpu usage was relativley high to me 20-30, with composite more like 40-60%. Compiled I rarely go above 10%, including compositing. I don’t know what it is, but self compiling just worked better. I used easy_e17 for a while and switched to my own package builds later. Archs package were pretty bare of configuration flags, however i think a lot of options are auto enabled. So I don’t know where the problem is.
None the less I’m happy to hear this I’ve been an e17 user since 2005, prior to that an e16 user. I have had great experiences with e17.
You clearly have something broken in your setup….. I’ve ran e17 on much slower hardware without any hitches are you running KDE4/Gnome applications in tandem with e17 thats probably the problem… you get all the bloat of Gnome + QT4 + e17 which makes it look bad and it really isn’t
Something is very wrong.
AntiX (E17 on Mepis) uses 2% cpu and around 60 megs of ram on my Athlon 4000+
Must be something wrong there. Installed Antix Linux with E17 on an old K6 2-550 box with 256 MB ram the other day, and even on that old chugger the CPU doesn’t go above 15% unless doing something intensive.
My problem with E17 has been its very unstable configuration. I play around in the settings and then it randomly begins to segfault. And it will segfault on boot every single time. My only chance is then to reset the configuration and start all over. That’s why I can’t use it on my laptop although I sure would like to.
Probably because you’ve used the unstable version? It is that simple :p Oh and E17 has not reached 1.0 yet.
but what about the WM? E17, when it’ll be released?
Someone here needs to install aspell.
Enlightenment is a great bit of programming in these days of gluttonous bloat. It’s very fast and very pretty. The problem I had with it was the stability. They sort that and I’ll switch to it full time on the craptop, maybe even on the desktop. Much better looking that LXDE. (It could also do with a better file manager.) It does make you realise just how fat things have become, it’s obscene how slow some things are on computers from even only a few years ago. Seams like you need to keep getting a faster computer just to stay still as things get fatter. Enlightenment goes against this trend, and that makes it a breath of fresh air.
Just run E16. It’s just as light (more so) and solid as a rock. The only issue I’ve seen since 2003 has been when I was out of disk space, which can fuck over your configuration.
At this point, as we sink into our pleasant reveries, a
truly enormous squadron of pigs flies past . . .2011 evrything hits the fan
The majority of the comments were on e17.
The article was on the Enlightenment libraries.
There is QUITE a gap. Not even close.
ok,so what other aplication out there uses the EFL as a base?? ….nothing…. one thing i really despise is that this is another toolkit that tries to reimplement c++ in part instead of just using a subset of c++ like fltk does.
Yeaaah… Not true…
Other than E17 who is using EFL to for their software?
Edited 2011-02-17 16:39 UTC
Samsung, for one, is using it for the main UI of a custom Linux-based OS.
iirc it’s already used in a number of other embedded devices.
Any links to mobile phone apps using the Enlightenment libraries? Can apps be compiled for iPhone, Android NDK or webOS PDK? Is hardware acceleration via OpenGL ES supported? I ask because these are things that Qt has been demonstrated to be able to do…. But if Enlightenment can do them, it’s nice to know there is an alternative…
input this URL:
( http://www.fashiongoods.us )
you can find many cheap and fashion stuff
(jor dan s-h-o-e-s)
(NBA NFL NHL MLB j-e-r-s-e-y)
( lv h-a-n-d-b-a-g)
(cha nel w-a-l-l-e-t)
(D&G s-u-n-g-l-a-s-s-e-s)
(ed har dy j-a-c-k-e-t)
(UG G b-o-o-t)
WE ACCEPT PYAPAL PAYMENT
YOU MUST NOT MISS IT!!!
( http://www.fashiongoods.us )