rleonardi wrote:Hi all,
I've been using OpenVG on RPi3 just for few weeks, so I am a very beginner about it. I'm not reaching "good" time performances for my specific application. Could you possibly answer the following questions:
- Do specific OpenVG (or other) settings exist to increase time performances? I tried by increasing memory for GPU, by overclocking RPi, but the results did not change.
- Do I have to explicitely enable the hardware acceleration?
- I started by referring to Shape library and its examples. Where could I find futher examples about OpenVG?
There's not really much in the way of settings to increase performance. Allocating more memory to the GPU may help by allowing the GPU to cache more paths if it does that (or at least allow you to allocate more).
As long as you link to the broadcom libraries then you'll have hardware acceleration. By default there is no software version - you'd actively have to find and install one if you wanted one (and the reference software implementation is slow).
ajstarks' Shapes library is good but it doesn't do things in a very optimal way. Whenever you ask it to draw say a circle, it creates a path for it, draws it and then deletes the path. This is not efficient at all. A more proper way is to allocate and define your paths as early as possible (preferably before your rendering loop) and keep them until you absolutely don't need them, that way all your have to do in your rendering loop is draw them in the right place. Reading the official spec document is a good place for information. https://www.khronos.org/registry/vg/spe ... vg-1.1.pdf
I forked ajstarks' library a while ago https://github.com/paeryn/openvg.git
(the windowsave branch is the most up-to-date) and have made various modifications to improve rendering speed whilst still keeping things (mostly) the way he did it. It retains the idea of drawing basic shapes but changes it so that it allocates paths for each shape on start-up and just alters the paths' coordinates when you draw them. I'm not sure that this is the best way either, but scaling a fixed path causes problems with stroking (drawing outlines) as the stroke gets scaled too (and you can only compensate by changing the stroke width if the scale is the same in both x & y directions).
Unfortunately there aren't many examples to be found using OpenVG, it never really took off on it's own (at least not in open source stuff). It probably mainly got used for hardware renderers of other vector libraries like SVG or Flash. Then mobile 3D GPUs took off and people wanted flashy 3D graphics instead of boring 2D.