[cairo] Switching to Evas Canvas over LGPL
DTurner at nds.com
Mon Aug 16 02:53:04 PDT 2004
> -----Message d'origine-----
> De : cairo-bounces at cairographics.org
> [mailto:cairo-bounces at cairographics.org]De la part de M. Evans
> Envoyé : samedi 14 août 2004 01:14
> À : cairo at cairographics.org
> Objet : [cairo] Switching to Evas Canvas over LGPL
> Indeed, as you say, "it's all about freedom, remember?" -- so
> me that Cairo does or will offer technical advantages over
> Evas, which,
> like Antigrain.com, retains a nice, friendly license.
> Explain what Cairo does that Evas does not -- if anything.
OK, I'll bite :-)
- Evas doesn't have Postscript/PDF/SVG output. It's really a
pixel-pushing engine that uses various tricks to get excellent
performance when compared to X11/XRender.
For example, when using the framebuffer backend, all rendering
happens in system memory with 32-bit ARGB surfaces, and only
the end-result is sent to video RAM. Since you _never_ read from
the frame buffer, drawing is _significantly_ faster than
XRENDER, but this uses gobs of memory. (Just like the pre-OpenGL
releases of Quartz).
Evas can also work with OpenGL to accelerate various operations
(e.g. compositing, scaling, etc...), just like Quartz Extreme.
In other words, Evas doesn't talk vectors internally, but it
does move pixels at really great speeds, with lots of different
backends (frame buffer, X11, DirectFB, XRENDER, etc...)
It provides a convenient "canvas" API that is targetted at
handling widgets (buttons, etc..). It supports hit-testing,
lazy-redraws, and it is capable of displaying anti-aliased
text (though I doubt it uses fontconfig or any standard
scheme to list/match fonts...).
I don't know anything about complext script support
in Evas, but I doubt it's there.
There is even some theorical chance that writing an Evas backend
for Cairo is doable.
- Cairo, by comparison, it focused on converting high-level
"vectorial" operations into various output formats, some of them
vector-based, like Postscript, PDF or SVG. It also includes
other back-ends that are capable of drawing into pixel
surfaces, X11 drawables, OpenGL surfaces, etc...
At the moment, Cairo is _massively_ slow at pixel rendering
compared to other vectorial libraries like libart or anti-grain.
I know this is because it tries to deal with extremely-high
For example, the path stroking algorithms in Cairo, libart
and anti-grain are vastly distinct, though I fail to see any
perceptual advantage by using the "very slow" one in Cairo
for the moment on a screen, I can imagine why this may be
important for PDF rendering at very high resolution.
However, this is an implementation detail that can be
optimized without changing the Cairo API one bit, so expect
some speedups in the future.
Cairo has a state-full API. It doesn't support hit-testing
for the moment.
- Anti-Grain is much more similar to Cairo than Evas is. However,
it's API is in C++ with templates (!!); it supports hit-testing.
The API has a very distinct style and isn't stateful (which isn't
necessarily a bad thing).
Anti-Grain includes an _optional_ vectorial polygon clipping
library that cannot be used in commercial projects. However,
Maxim is currently rewriting it in C++ to release it under
the AAG license. There is also a "free" scan-line based
polygon clipper that is about 10x faster on typical
desktop (screen) usages.
One funny thing with the AAG API is that it can be used to
create a rendering pipe-line by "connecting" various "filters"
that can act either on vectors or pixels. This allows you to
make all kinds of funny effects very easily (e.g. perspective
transform of SVG images with maximal pixel-level accuracy)
without needing a very complex "static" API. This also allows
you to tailor the rendering to your needs.
I don't think there are PDF/PS/SVG backends for AAG, but writing
classes to handle this should be possible, though a lot of work.
- Libart is vector rendering library that supports various
"standard" operations like path stroking, image scaling, pattern
and gradient fills. It's reasonnably fast, though it's API is
much more low-level than Cairo. For example, the concept of
SVPs (Segmented Vector Paths) should have stayed an implementation
detail, instead of being a big part of the public API. Sames goes
with MTAs (Micro-Tile Arrays). Moreover, these "concepts" are
rather hard to grasp to many developers, which makes the API
a bit harder to understand at first. However, this can quickly
be overcome with practice.
Basically, each project has its strengths, so choose wisely
depending on your needs. Until then, Cairo had the advantage
of being tagged as the "standard" API for vectorial rendering;
time will tell if the license change will have an impact on
Hope this helps,
- David Turner
- The FreeType Project (www.freetype.org)
> Then we can
> decide whether Cairo's technical merits outweigh its new license and
> make an informed choice. In this manner you can help us to
> exercise our
> cairo mailing list
> cairo at cairographics.org
More information about the cairo