Ecore_Wl2: An EFL Library for Wayland Applications

Throughout the years of developing Wayland support for EFL, few EFL libraries have had as much impact on EFL Wayland applications as the Ecore_Wayland library has. This library was one of the first to make it possible to truly run EFL applications in a Wayland environment. As the years progressed, it became apparent that Ecore_Wayland had some shortcomings; this blog post will introduce you to the replacement for Ecore_Wayland, called Ecore_Wl2.

Ecore_Wayland’s Shortcomings

While testing our first Wayland implementation, it became apparent that the initial implementation of the Ecore_Wayland library had some drawbacks. Publicly exposed structures could not be changed easily without breaking existing applications, and any changes to existing Wayland protocols would require significant changes to our Ecore_Wayland library. It was also discovered that when an EFL Wayland application creates a new window, the backend library also creates an entirely new display and connection to the Wayland server. This resulted in high memory usage in EFL applications.

Due to these shortcomings, the community decided that EFL should have a better library for integrating with Wayland, and thus Ecore_Wl2 was born. Determined not to repeat the mistakes of the past, I began the long and arduous task of giving birth to a new library.

Building a More Capable Library

One of the first tasks with the new library was to move structures fields out of the public API so they could later be changed without breaking existing applications. As a result, in Ecore_Wl2 there are some publicly exposed structures (via Ecore_Wl2.h header file), however, the individual fields of these structures are not directly accessible. There are now public API functions to retrieve structure members to allow some access to these fields; this makes it possible to make necessary changes in the future while also maintaining existing applications.

The next area of focus for the new library was to reduce memory usage. In the older library, every window of every application would create it’s own Ecore_Wayland_Display: a huge waste of resources. I decided to implement display caching; this means the library code now maintains a cache of existing displays. When an application requests a display it calls ecore_wl2_display_connect():

EAPI Ecore_Wl2_Display *
ecore_wl2_display_connect(const char *name)

However, behind the scenes the library checks for any existing displays in the cache that match the given display name and return it. If no display is found in the internal cache, a new one is created and cached. This allows for display reuse without added memory overhead, especially for an application that intends to create more than one window. Since we use this new library in the server implementation, caching server displays has also been implemented.

While this blog post has briefly touched on the new Ecore_Wl2 library, I invite everyone to keep an eye open for another upcoming post concerning the Ecore_Wl2 library. It will go into more detail related to the improvements the library provides and how to make use of it.

Author: Chris Michael

Chris Michael has been an EFL/Enlightenment developer for over 13 years and is now working for the Samsung Open Souce Group.