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.
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)
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.
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
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.