Inquiry on OpenVG

Hi there,

I have some doubts regarding OpenVG API, please help. The doubts are:
a. Is it correct to say that the OpenVG API is created based on the SVG specification?
b. If yes, may I know that which SVG profile is refer to for OpenVG API 1.0?
c. Is OpenVG API support the opacity function?

Looking forward to receive info from you.

Thanks & have a nice day.

Cheers,
Chloe

SVG, as you probably know, is an XML based description language.
OpenVG is a programming API.
The OpenVG 1.0 spec was designed to easily implement applications which display SVG files which follow the “SVG Tiny” spec. OpenVG 1.1 added some functionality to allow for development applications rendering SWF files (as well as fonts, etc). The API is not limited to only be used in these ways however.

That said, I don’t believe group opacity is part of the SVG Tiny spec. Object Opacity can be handled normal with the SRC_OVER blending mode, but group opacity must be rendered to a an off screen buffer, then blit onto the screen with vgDrawImage() [using multiply mode, and a white paint with the correct opacity]. So yes, group opacity is a bit cumbersome.

I will point out that even though the group opacity flag is often set in SVG files, the group often contains only one path or multiple paths which do not overlap. In this case, it’s much more efficient to multiply the opacities for the group and path(s) and render it/them normally.

Thanks for the useful info.

Can OpenVG 1.0 implement all the application which display in SVG tiny profile?
For example: painting, hyperlinking, image module, text, font & animation?

And, last question: Can OpenVG 1.0 implement gradient application in SVG files?

As far as I know, yes, OpenVG can support all the rendering states possible in SVG tiny (all the path styles, stroke styles, end caps, join styles, dashing, blend modes, paint types [i.e. gradients], etc). With the exception of group opacity, and a few obscure blending modes, it can support most of the regular SVG spec too. (Disclosure: I’m not as comfortable with the SVG spec as the OpenVG spec)

Word of warning - it is not a simple 1 to 1 XML -> OpenVG API translation in some cases, and some work will need to be done. You’ll probably want to use support libraries like FreeType to help with font loading, and any scripting and animation from the full SVG spec will have to be handled by your application. There is a bunch of internal state you will also have to manage, like matrix stacks and managing the various paint and path objects used by OpenVG. OpenVG just handles the rendering - nothing more.

That said, you probably want to be using OpenVG 1.1 instead of 1.0 - for 2 reasons. First is the much better font support, and the second is an issue with how dashing was handled for multi-section paths that was incompatible between SVG and OpenVG. A flag to allow the SVG style behavior was added to the newer specs (I think it’s already in OpenVG 1.0.1).