[cairo] Switching to Evas Canvas over LGPL

[Turner, David]

> -----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
> 
> 
> 
> Carl,
> 
> Indeed, as you say, "it's all about freedom, remember?" -- so 
> persuade 
> me that Cairo does or will offer technical advantages over 
> Evas, which, 
> like Antigrain.com, retains a nice, friendly license.
> 
> http://enlightenment.org/pages/evas.html
> http://enlightenment.org/pages/htmlized/evas/
> http://www.directfb.org/mailinglists/directfb-users/2002/11-20
> 02/msg00059.html
> http://www.osnews.com/comment.php?news_id=7888&limit=no#266628
> 
> 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
  quality rendering.

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


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 
> freedom.
> 
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://cairographics.org/cgi-bin/mailman/listinfo/cairo
>