OVG, flash and floating point on embedded platforms


I will appreciate your expert comments on the following issue.

I am looking into adobe flash content rendering using OVG accelerators on embedded platforms. OVG APIs are floating point and so is flash (.swf) content (as far as i understand). These combined, it seems to me there is a problem in embedded space where CPUs are not strong and FPU is often missing. Suppose we only manipulate bitmaps and glyphs. Unless there is a way to calculate all transformation matrices (let’s assume the bitmaps are always rendered in predefined locations and orientations, such as is the case of cover flow UI) “offline”, I doubt we can get fair framerate.


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


thank you very much for the guidance. Indeed, there are HW accelerators and those have an integer path. My concern however is applications. Of cause, we can write native OVG code that will use as much integers as possible, but what if I want to run flash (.swf) content? - this one will be full of floating point manipulations. I think OVG was developed to support flash, so I am puzzled at the apparent discrepancy here. Unless there is a way to make arbitrary flash content to contain only integers I don’t see much use in OVG hardware on platforms without FPU.

While I have read the swf spec, I have not done a performance analysis of it, but I’m pretty sure you’ll find that the time needed to parse the swf file and send out the various OpenVG commands, will be far far smaller than the actual rendering time - even if you end up using emulated floats and OpenVG is fully hardware assisted.

Basically though, all you’ll be doing involving actual FP arithmetic is scaling a bounding box or two and managing a matrix stack (or am I forgetting something?) - that’s kind of insignificant when you compare it the rest of the OpenVG pipeline. If anything you have to do requires a large amount of FP math, just convert it to fixed point (if possible), do the arithmetic, and convert it back if it ends up being a bottleneck.


I guess I have to dig deeper into SWF format to understand whether FP should be a concern or not. Thanks for the tips.