Ah yes, the joys of floating point on embedded systems…
If your platform does not support floats natively, then hope the OpenVG driver converts everything to fixed point as soon as it can otherwise performance will be dreadful. In any case though, that’s for the driver to worry about. As long as there is a fixed point path in the driver, and you stay within reasonable parameters (i.e. not scaling and translating by large factors), you should get good enough performance. An optimization guide for the OpenVG driver you are working on is the place to look for what you should do to make the driver happy (for example the driver might prefer integer path data instead of float path data or vice-versa [datatype is selectable when you create the path]).
That said, there are bits of the OpenVG pipeline that require floating point precision (Matrix transforms for example). I understand the OpenVG conformance test is quite stringent on some of the precision requirements on some of it’s tests (in fact too much so…). Generally though, even if the Matrix transforms end up being emulated, the actual rendering is still the most time intensive process.
If there are “OVG accelerators” on your platform though, it’s almost certain that there is some hardware in there to prevent the need to do software emulation of floating point arithmetic (i.e. the “OVG accelerators” will contain an FPU of some kind [maybe not IEEE-754 compatible, but something]). If there is an OpenVG driver specifically for your platform, then chances are someone probably has tried to make it run quickly regardless (so don’t worry about the float issue too much). If you’re looking for a general software based OpenVG driver, then you’ll need to find one which uses fixed point for back end rendering or performance will be bad (this is not an uncommon technique - cairo [used by firefox] uses this technique for example).