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

[Adam Jackson]

On Tuesday 09 August 2005 14:21, Carl Worth wrote:
> 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.

I would expect this to be the more natural thing to do.  Conceptually VG sits 
at the same level as GL in the stack, and both VG and GLES use the EGL API 
for context and window management.  You could implement EGL over cairo but 
it'd be awkward.

VG is more like an abstract state machine model of the hardware, rather than 
an API for actually getting stuff drawn.  In particular, the intent is for 
IHVs to start supplying OpenVG stacks that implement hardware acceleration 
directly, meaning, that's the layer where the hardware interface starts.  
Cairo doesn't belong below that layer.

I've toyed with the idea of doing something like the Mesa drivers for OpenVG, 
where you have a shared software core engine and some hooks to push the 
commands down to the hardware through the DRI interface.  I don't know how 
practical that is on consumer-level video cards yet, but I expect something 
like a DS or PSP would have some use for this.

> 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:

So what's the cairo equivalent of glGetString and glXGetProcAddress?

GL gets extended on a per-vendor basis.  If you restrict your get/set 
functions to only take a subset of enums, then you need new state 
manipulation entrypoints for each extension.  That becomes a huge dispatch 
table because GL has a terrifying amount of state.  Recentish Mesa has about 
1100 entrypoints in the GL and GLX namespaces.  Passing glGet down to the 
driver is a trivial hook.  Passing 300 unique Gets down to the driver is big 
and ugly.

The multivendor style of GL means you have to look up the doc for the 
extension anyway, since most of the fun ones aren't in the core.  And at that 
point, whether your magic token is an enum or a #define is largely 
irrelevant, because right next to "what it does" in the spec is "what 
function you pass it to".  It does scale remarkably well (libGL is far more 
pleasant to deal with than the explosion of X extension libs), but scaling 
isn't free.

Maybe Cairo can take a different approach since there's only one Cairo.

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

This sounds like an even stronger argument for Cairo to wrap VG instead of the 
other way around.  Higher layers should be nicer for the programmer.  VG 
certainly looks capable, but as with core GL you might not want to use it 
raw.

- ajax
-------------- 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/bbeaaccd/attachment.pgp