gEvas: the GTK+2 to Evas Bridge

Learn about some of the Enlightenment Foundation Libraries and how to use them with gEvas for high performance in your next GTK+2 application.

The Evas library provides a canvas for quickly rendering raster
graphics with alpha blending support. Evas is part of the
Enlightenment Foundation Libraries (EFL), a suite of libraries
originally built to support Enlightenment DR 17. Other libraries in the
EFL that complement Evas are the Edje and Embryo combination and the
Emotion library. Edje allows you to wrap up fonts, graphics and
functionality into portable theme-like files.
Embryo is a simple yet Turing complete scripting language that enables
simple scripts to be embedded into Edje files. Emotion allows you to have
many video streams as first-class canvas objects. This means you can alpha
blend video, move video objects around, resize them and layer them in
the canvas while playing.

gEvas is a wrapper and glue library built to allow Evas to be used
from GTK+2.x applications easily. In order to motivate you to try gEvas,
I present here the points that originally motivated me to use Evas and
subsequently create gEvas. My major motivations to use Evas were its
simple API and great render speed for an alpha-blended canvas.

Making claims of high render speed unfortunately
requires a brief trip into the benchmarking world.
The evas_bench application from the Evas distribution
involves many pixmap canvas items, scaling and
blending of pixmap items and text elements. The
image scaling is nowhere near as extreme as the
above resize benchmarks. I have ported evas_bench
to using GNOME Canvas.

Figure 1 shows a screenshot of the GNOME Canvas port of evas_bench.
I have also created some simpler
tests for the canvas scaling algorithm both with and without forcing
alpha blends on each frame.
For the non-alpha-blended version, a leaf image is resized from larger
than full-canvas width to 0 by 0 and back again in a loop; see Figure 2.
For the alpha-blended version, a red rectangle image of the same size as
the leaf image was used ranging from 0 alpha in the top left to full
alpha in the bottom.

Figure 1. GNOME Canvas port of evas_bench tool. Many images and text are
moved and resized around the canvas.

Figure 2. gEvas version of gnome_canvas scaling and compositioning benchmark.
The leaf is resized gradually to retract to the top left of the canvas and
then return to this original size again.

As stated above, I created gEvas, and some readers may notice that I am
a part of the Enlightenment developers team. Although this is true, I have
gone to lengths to ensure that the benchmarks are not biased. The benchmark
source code is available (see the on-line Resources). Those reading the source, please
excuse the excessive use of less-than-optimal coding conventions used in
the quick code hack.

For those unfamiliar with GNOME Canvas, it has two rendering back ends.
From the GNOME Canvas developer documentation (see Resources):
“...It [GNOME Canvas] offers a choice of two
rendering back ends, one based on Xlib for extremely fast display, and
another based on Libart, a sophisticated, anti-aliased, alpha-compositing
engine.” Evas attempts to provide the best of both worlds. I benchmark
Evas against both GNOME Canvas rendering engines.

There are also reasons why Evas might not be an appropriate choice.
GNOME Canvas supports a Bezier path canvas item that, at present, Evas
does not support. In addition, Evas and gEvas are less likely than GNOME
Canvas to be preinstalled.

Evas may get beziers in the future. The summary of this point from
Raster (aka Carsten Haitzler) was: “If you are after a vector
editor suite or something, GNOME Canvas is
better. If you want real time fast, alpha-blended object display on all
targets, Evas is a good choice.”

Evas itself supports multiple back-end render targets,
including the framebuffer, XLib and OpenGL. At present,
gEvas uses only the XLib Evas back end. However, as GTK+2
can run on the framebuffer, you should be able to use gEvas on
the framebuffer too, but this is untested.

Both GNOME Canvas and Evas share a similar data model. The Qt QCanvas data model
is different enough to make clean benchmark comparisons difficult.
The first major difference that makes comparisons difficult is how QCanvas handles images.
To put an image on the canvas, you create a QCanvasSprite with a single frame.
To scale that image, you then use QImage::scale() or
QImage::smoothScale(), which
gives you back an image that you can use to update your sprite. This puts image scaling
and the cache handling for scaled images into the client application.
Both Evas and GNOME Canvas allow canvas objects to be resized directly and thus take responsibility for
handling the caching of scaled images for you.

The second difference is that Qt gives you control over the update tile size.
The Qt documentation recommends:
“A good rule of thumb is that the size should be a bit smaller than the
average canvas item size. If you have moving objects, the chunk size
should be a bit smaller than the average size of the moving
items.”

Due to the data model differences, I haven't created a Qt port of
evas_bench as yet. I did create a canvas scaling and blending client,
although there are some canvas design issues affecting a clean comparison.

With Qt moving the cache policy fully in the client, I have chosen to
cache all scaled images in the first iteration of scaling and reset the
benchmark start timer for further iterations that will use only the cache.

So keep in mind that the Qt resize benchmark is performed with all
resized images pre-cached and many user-specified tile sizes are used
for benchmarking. This effectively should give QCanvas a huge speed
advantage over Evas and GNOME Canvas.