[cairo] Cairo versus OpenVG, any feature comparision available ?

[Carl Worth]

On Tue, 09 Aug 2005 20:54:00 +0200, Stephane LOEUILLET wrote:
> with cairo approching 1.0 release and OpenVG specs just released (in
> July in fact), it looks at first sight that both API have a same goal :
>  hardware accelerated 2D graphics.

It's worth mentioning that there are significant differences in the
way the two APIs have been developed. I'm definitely not a fan of the
behind-closed-doors model that lead to the appearance of the OpenVG
specification. Though, I do applaud the fact that the specification is
now public and made available under royalty-free terms.

Beyond the development process, there are also significant technical
differences in what the two APIs try to accomplish. I haven't read
through the OpenVG specification in detail, but I have skimmed through
the sample header file.

As already mentioned, a significant capability difference between
cairo and OpenVG is the fact that cairo provides multiple backends,
aiming to unify display and print output. Another is that OpenVG
provides no direct support for fonts or text, which are often the
dominant element of 2D user interfaces.

There are also different API design influences affecting both cairo and
OpenVG[*].

> If so, would it be possible to make a cairo back-end that uses OpenVG
> driver ? (could all cairo operations be mapped to OpenVG calls ?)

There are two things that could be done here:

1) It looks like it would be rather straightforward to implement a
   cairo backend that did its drawing with OpenVG,
   (ie. cairo-openvg.h). There may be some cairo operations that don't
   map directly to OpenVG, but for any such cases, we already have a
   reasonable model within cairo for selectively falling back to
   software.

2) Another thing that would be possible would be to implement the
   OpenVG specification itself with cairo. Again, most of this looks
   fairly straightforward, though there are a few pieces of OpenVG
   that would likely need new code, (some image formats, the multiply
   and stencil image modes?, scissoring?, etc.). It might make sense
   for some of that new code to live within cairo itself, and for
   other pieces it may make more sense to live in a new layer above
   cairo.

Whether either of the above projects is actually a compelling thing to
do is not clear to me. That would depend on what interesting
hardware/software might appear in the future that either implements or
uses OpenVG.

I don't see any evidence of an available reference implementation of
OpenVG. It would be interesting if the first publicly available
implementation to appear were made entirely from free software.

-Carl

[*] Here are some rambling comments on API design. This is a bit
off-topic with respect to the rest of this message, but I've typed it
all now, so here it is.

I can really only comment cairo's API design, (not having been a part
of or privy to the OpenVG design process). But cairo's API design has
been something that I've personally put a lot of effort into over the
past 2 or 3 years. An important emphasis in cairo is making the API
very easy to use directly, with hopefully minimal need to continually
consult the reference manual. Some of the aspects of cairo's design
that help this are short parameter lists, consistent naming, and as
much type-safety and compile-time checking as possible. For example
setting the fill rule or line width parameters in cairo is
accomplished with the following two functions:

	typedef enum _cairo_fill_rule {
	    CAIRO_FILL_RULE_WINDING,
	    CAIRO_FILL_RULE_EVEN_ODD
	} cairo_fill_rule_t;

	void
	cairo_set_fill_rule (cairo_t *cr, cairo_fill_rule_t fill_rule);

	void
	cairo_set_line_width (cairo_t *cr, double width);

OpenVG appears to have influences similar to OpenGL. Rather than
having separate functions for setting individual parameters, OpenVG
provides generic set/get functions which are keyed by a VGParamType
enum indicating which parameter is being set. Then there are
variations of the set/get for each of the possible data types for the
values. For example:

	typedef enum {
	  /* Mode settings */
	  VG_FILL_RULE                                = 0x1101,
...
	  /* Stroke parameters */
	  VG_STROKE_LINE_WIDTH                        = 0x1110,
...
	} VGParamType;
	
	typedef enum {
	  VG_EVEN_ODD                                 = 0x1900,
	  VG_NON_ZERO                                 = 0x1901
	} VGFillRule;

	VG_API_CALL void vgSetf (VGParamType type, VGfloat value);
	VG_API_CALL void vgSeti (VGParamType type, VGint value);

This approach dissociates the declared values from the functions that
accept them. For example, imagine a programmer wanting to perform an
even-odd fill. After finding VG_EVEN_ODD in the header file, what's to
be done with this value? The VGFillRule type does not appear in the
header file aside from the enum declaration. No function is explicitly
defined to accept a VGFillRule parameter. So the programmer has to
learn (or guess) which is the correct function to call. And any
mistake will not be identified until run-time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050809/c34aef77/attachment.pgp