Developers looking to add GUIs to their embedded devices have a variety of open source and commercial options, with Qt generally leading the list. If you’re operating in severely constrained environments, however, especially for battery powered devices like wearables, the open source Enlightenment Foundation Libraries (EFL) should be given close consideration.
At the recent Embedded Linux Conference, Cedric Bail, a long-time contributor to the Enlightenment project who works on EFL integration with Tizen at Samsung Open Source Group, discussed some of the lessons learned in optimizing wearable apps for low battery, memory, and CPU usage. Bail summarized EFL and revealed an ongoing project to improve EFL’s scene graph. However, most of the lessons are relevant to anyone optimizing for wearables on any platform (see the ELC video below).
EFL has been under development for 10 years and was released in 2011. It was designed as a toolkit for the 20-year old Enlightenment, the first windows manager for GNOME. Today, however, it has evolved to feature its own rendering library and scene graph and can work with a variety of windowing environments. The EFL project is in the process of adding an optimized Wayland support.
Samsung was an early supporter of EFL and is still its biggest champion. The CE giant now uses EFL in its Tizen-based Samsung Galaxy Gear smartwatches, as well as its smart TVs, and several other Tizen-based devices.
Like Enlightenment, EFL was designed from the start for embedded GUIs. The toolkit is licensed with a mix of LGPL 2.1 and BSD, and written in C, with bindings to other languages. EFL is primarily designed for Linux, although it’s lean enough to run on RTOS- and MCU-driven devices such as the Coyote navigation device.
“EFL is optimized for reducing CPU, GPU, memory, and battery usage,” said Bail. “It takes up as little as 8MB, including all widgets. Some have pushed it lower than that, but it’s less functional. Arch Linux can run with EFL on 48MB RAM at 300MH, with a 1024×768 screen in full 32-bits display, and without a GPU. EFL does better than Android on battery consumption. That’s why Samsung is using Tizen on its smartwatches.”
Despite its minimalist nature, EFL supports accessibility (ATSPI) and international language requirements. It’s also “fully themable,” and can “change the scale of the UI based on the screen and input size,” said Bail. “We also account for the DPI and reading distance of the screen for better readability.”
Bail disagrees with the notion that improvements in power/performance will soon make minimalist graphics toolkits obsolete. “Moore’s Law is slowing down, and it doesn’t apply to battery life and memory bandwidth,” said Bail.
Optimizing the UI is one of many ways to reduce your embedded footprint. In recent months, we’ve looked at ELC presentations about optimizations ranging from shrinking the Linux kernel and file system to streamlining WiFi network stacks to trimming energy consumption on an oceanographic monitoring device.
The UI is typically the most resource-intensive part of an application. “Most applications don’t do much,” said Bail. “They fetch stuff from the network, a database, and then change the UI, which does all the CPU and GPU intensive tasks. So optimizing the UI saves a lot of energy.”
The biggest energy savings can be found in the UI design itself. “If your designer gives you a 20-layer UI with all these bitmaps and transparency, there is very little our toolkit can do to reduce energy,” said Bail.
The most power-efficient designs stick to basic rectangles, lines, and vertical gradients, and avoid using the entire screen. “If you have full-screen animations where things slide from left to right or up and down, you can’t do partial updates, so it uses more energy,” said Bail. If you’re targeting AMOLED screens, consider using a black background, as the Enlightenment project does on its own website. “Reddit running in black consumes 41 percent less energy on Android AMOLED phone,” Bail added.
One other trick used on the Gear smartwatches is an integrated frame buffer within the display. “The system can completely suspend the SoC, while the display refreshes itself, and save a lot of battery life, which is fine if you’re just displaying a watch face.”
Memory optimization is another area where you can substantially reduce consumption. “All rendering operations are constrained by memory bandwidth,” said Bail. “And if you want to run a web browser, memory declines quickly.”
Memory consumption is primarily driven by screen size, which is not usually an issue for a smartwatch. There are other ways to optimize for memory usage, however, such as avoiding true multitasking and using CPU cache.
“Accessing main memory uses more energy than accessing the CPU cache,” said Bail. “You can optimize by improving cache locality and doing linear instead of random access. You can look for cache locality with Cachegrind and visualize it with Kcachegrind, and you can hunt for leaks and overuse with tools like massif and massif-visualizer.”
Power reduction in wearables can produce all-day battery life, as well as reduce dissipated heat for greater comfort, said Bail. Lower battery consumption also provides “more freedom for designers, who may want to go with a thinner device using a smaller battery.”
Wearables developers should also optimize for speed, which means “doing things more efficiently and avoiding unnecessary complications,” said Bail. This also applies to the GPU where you can optimize redrawing the screen if nothing has changed, or doing partial updates and reusing information from a past image. You should also trigger animations “only at speed the hardware is capable of,” he added.
The EFL project uses the Raspberry Pi as a target for speed optimization, and runs tests with Kcachegrind. For EFL, Bail recommends that Pi users adopt the more up-to-date Arch Linux over Raspbian.
Network optimization is also important. “When you send data, you are more likely to lose packets, which means you have to retransmit it, which takes energy,” said Bail. “You want to send as little data as possible over the network and download only what is needed.”
Optimizing downloads is a bit tricky because “this is usually a prefetch, and you don’t know if the user will need all of the download, so you may end up over-downloading something,” said Bail. “You should group your downloads together, and then switch to full network idle for as long as possible.” Otherwise, energy is consumed by wireless stacks time switching between energy states.
When optimizing specifically for battery use, developers rely on the Linux kernel. The kernel chooses the clock, voltage, and number of active cores “by trying to figure out what you are going to do even though it has no idea what you are doing,” said Bail. “For years, the kernel failed at this,” he added.
The problem comes from the kernel scheduler basing its decisions solely on past process activity whereas digital reality can be much more dynamic. Among other problems, the scheduler “forgets everything as soon as it migrates to another CPU core.” There are also complications such as the CPU frequency driver and CPU idle driver both looking at system load, but without coordinating their activities.
In the past, developers tried to overcome this problem with an energy aware userspace daemon equipped with a hard-coded list of applications and their corresponding behavior. ARM and Linaro are working on an a more dynamically aware solution called SCHED_DEADLINE as part of its Energy Aware Scheduling (EAS) project. The technology, which was covered in a separate ELC 2017 presentation by ARM’s Juri Lelli, promises to link CPU frequency and idle to the scheduler, while also retaining more information about past loads.
“SCHED_DEADLINE will let interactive tasks become properly scheduled by the system,” said Bail. “The userspace will break things apart in a thread that is dedicated to specific things.” With the new infrastructure, interactive tasks will be able to change behavior very quickly, even during the 16ms rendering of a frame.
With the increasing use of multi-core processors, the original EFL scene graph switched a few years ago to a dual-thread version. Now the project is developing a new version that will work in harmony with SCHED_DEADLINE.
The scene graph is “a bookkeeping of primitive graphical objects, of everything you draw on the screen,” said Bail. “It has a general view of the application from inside the toolkit so you can do global optimization.”
With the current dual-thread scene graph, “the kernel may have a hard time figuring out what is going on in the main loop,” explained Bail. “Our new version will help this by grouping computation — such as CPU-intensive tasks for generating spanline for shape, and decompressing image — into a specific thread for screen-intensive tasks, and grouping all the memory-bound computations in their own thread.”
The new scene graph is not without its drawbacks, however. “The main price we pay is increased memory usage because we need more threads,” said Bail. “Every thread has its own stack, which causes increasing complexity and new bugs. We are trying to patch all these risky things inside the toolkit.”
You can watch the complete video below:
Connect with the Linux community at Open Source Summit North America on September 11-13. Linux.com readers can register now with the discount code, LINUXRD5, for 5% off the all-access attendee registration price. Register now to save over $300!
