[cairo] Cairo versus OpenVG, any feature comparision available ?
ajax at nwnk.net
Tue Aug 9 12:39:21 PDT 2005
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
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
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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050809/bbeaaccd/attachment.pgp
More information about the cairo