How to increase OpenVG time performances

[rleonardi]

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?
Thanks.
Ciao

[Paeryn]

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?
Thanks.
Ciao

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.

[rleonardi]

Hi Paeryn,
Thank you very much for all the information.
I'll immediately try the changes like "creating the paths at the beginning", etc.
Ciao

[rleonardi]

Hi Paeryn,

I'm trying to use the Shape library as in https://github.com/paeryn/openvg/tree/windowsave. I'm getting an error. By executing the following commands:

sudo apt-get update
sudo apt-get dist-upgrade
sudo reboot
sudo apt-get install libjpeg8-dev indent libfreetype6-dev ttf-dejavu-core libfontconfig1-dev
cd /home/pi
git clone git://github.com/paeryn/openvg
cd openvg
git checkout windowsave
make

I get error "fontsystem.c:9:10: error: #include expects "FILENAME" or <FILENAME>".

Line 9 of fontsystem.c is "#include FT_FONT_FORMATS_H".
Line 6 includes ft2build.h, which includes ftheader.h.
In /usr/include/freetype2/config/ftheader.h, I can find FT_FREETYPE_H and FT_OUTLINE_H, but not FT_FONT_FORMATS_H.

Maybe the "sudo apt-get install" install a wrong version of freetype?

Thank you for any help.
Ciao

[Paeryn]

I get error "fontsystem.c:9:10: error: #include expects "FILENAME" or <FILENAME>".

Line 9 of fontsystem.c is "#include FT_FONT_FORMATS_H".
Line 6 includes ft2build.h, which includes ftheader.h.
In /usr/include/freetype2/config/ftheader.h, I can find FT_FREETYPE_H and FT_OUTLINE_H, but not FT_FONT_FORMATS_H.

Maybe the "sudo apt-get install" install a wrong version of freetype?

Thank you for any help.
Ciao

It should be there. It's defined on line 719 of /usr/include/freetype2/config/ftheader.h
What version is installed? (apt-cache policy libfreetype6-dev will tell you), my version of libfreetype6-dev is 2.6-2rpi1rpi1g. Although apt-cache says that version 2.5.2-3+deb8u1 is also available and looking online the font formats header file isn't in that version. It's strange if they've changed to providing an old version when they used to provide a more recent one. I installed it back in November last year according to the timestamps, definitely using apt-get on the default raspbian repo.

I think I missed naming a package needed, libpng12-dev is also required though that won't affect freetype.

<Edit> libfreetype6-dev is listed as the 2.6 version on archive.raspberrypi.org, but the 2.5 version on mirrordirector.raspbain.org

[rleonardi]

Hi Paeryn,

pi@raspberrypi ~/openvg $ apt-cache policy libfreetype6-dev
libfreetype6-dev:
Installed: 2.5.2-2rpi1rpi1
Candidate: 2.5.2-2rpi1rpi1
Version table:
*** 2.5.2-2rpi1rpi1 0
500 http://archive.raspberrypi.org/debian/ wheezy/main armhf Packages
100 /var/lib/dpkg/status
2.4.9-1.1+deb7u3 0
500 http://mirrordirector.raspbian.org/raspbian/ wheezy/main armhf Packages


Moreover, at line 719 of /usr/include/freetype2/config/ftheader.h, there is "FT_XFREE86_H". At https://www.freetype.org/freetype2/docs ... _FORMATS_H, they say that FT_XFREE86_H is deprecated.

Does it mean that "sudo apt-get install libjpeg8-dev indent libfreetype6-dev ttf-dejavu-core" now load a deprecated version of freetype? Or maybe I'm doing something wrong, for ex. getting files from a wrog repository by using apt-get?

Thanks.
Ciao

[Paeryn]

Ahh, you're still on Wheezy, that's old. On an RPi3 too?

The deprecated thing is the FT_XFREE86_H, I think FT_FONT_FORMATS_H replaced it, currently FT_XFREE86_H is just defined as FT_FONT_FORMATS_H so you could try changing FONT_FORMATS for XFREE86 in fontsystem.c to see if it allows it.

[rleonardi]

>> Ahh, you're still on Wheezy, that's old. On an RPi3 too?

Yes. I just moved the SD card from RPi2 to RPi3. Moreover, in /etc/apt/sources.list I can see "deb http://mirrordirector.raspbian.org/raspbian/". So I think this is why I'm not getting the 2.6-2rpi1rpi1g_armhf.deb from archive.raspberrypi.org.

>> The deprecated thing is the FT_XFREE86_H, I think FT_FONT_FORMATS_H replaced it, currently FT_XFREE86_H is just defined as FT_FONT_FORMATS_H so you could try changing FONT_FORMATS for XFREE86 in fontsystem.c to see if it allows it.
Yes, FT_FONT_FORMATS_H replaced FT_XFREE86_H.
Just changing FONT_FORMATS for XFREE86 in fontsystem.c seems to do not work. When I compile my application, the compiler says "undefined reference to FT_Get_Font_Format()", which is in freetype/ftfntfmt.h, but this file does not exist in the 2.5 freetype version.

Any suggestions?

Should I migrate to jessie?

Thanks!

[Paeryn]

I'd definitely suggest moving to Jessie unless you need Wheezy for anything, I don't know if Wheezy gets updates any more.

There'll be extra stuff in FONT_FORMATS above what was in XFREE86, was worth a shot though just in case I didn't use any of the newer functions.

The raspbian.org entry is in /etc/apt/sources.list, raspberrypi.org entry is in /etc/apt/sources.list.d/*.list (I can't remember the exact file name but it's in one of those that directory).

If you didn't want to upgrade to Jessie you could always compile the latest freetype2 yourself but then you'd have to sort things out with the package manager.

[rleonardi]

Hi Paeryn,
I migrated to jessie, updated ("sudo apt-get update", "sudo apt-get dist-upgrade", "sudo reboot") and reinstalled shapes by following the instruictions in https://github.com/paeryn/openvg/tree/windowsave. The time performarnces of my application have not changed.
Any further suggestions?
Thanks.
Ciao

[rleonardi]

By testing, the very most time consuming function seems to End(), that is eglSwapBuffer(). For ex, if I put n.2 consecutive calls of End() (instead just the one), the time of each loop is n.2 times. If I put n.3 consecutive calls of End(), the time of each loop is n.3 times.

[Paeryn]

That all depends on what your program is doing. Is it doing a lot of drawing each frame? If you only do a few drawing operations then you won't see much difference. What do you categorise as "good" time performance?

Also, did you re-build your program with the new library (just thinking in-case you had statically linked to the old one)?

<Just seen you're next reply>

The screen is updated in sync with the refresh rate. If you were getting the full 60fps with one End(), just by putting End(); End(); you will go down to 30fps.

[rleonardi]

>> That all depends on what your program is doing. Is it doing a lot of drawing each frame?
I would say no. For ex, for each loop I call n.9 times Arc() and n.9 times Polygon() (the polygon is a triangle), and it takes more than 10000usec.

>> Also, did you re-build your program with the new library (just thinking in-case you had statically linked to the old one)?
Yes I did.

>> The screen is updated in sync with the refresh rate. If you were getting the full 60fps with one End(), just by putting End(); End(); you will go down to 30fps.
Yes, now I can see it. By tracing the time, I can see about 16500usec betewen consecutive End() calls.

[rleonardi]

I can see that Arc() takes about 400:500 usecs and Polygon() takes about 250:300 usecs. Are these time consume values the ones expected? Am I doing something wrong in configuring OpenGL or something else?

By looking into libshapes.c, I can see that:
- Arc() calls newpath() and vguArc(), instead of calling vgModifyPathCoords() as vgModifyPathCoords() does. What is the reason?
- Arc() does not call vgDestroyPath(). Is it correct?

Thanks

[Paeryn]

I can see that Arc() takes about 400:500 usecs and Polygon() takes about 250:300 usecs. Are these time consume values the ones expected? Am I doing something wrong in configuring OpenGL or something else?

By looking into libshapes.c, I can see that:
- Arc() calls newpath() and vguArc(), instead of calling vgModifyPathCoords() as vgModifyPathCoords() does. What is the reason?
- Arc() does not call vgDestroyPath(). Is it correct?

Thanks

Not sure about timings of individual shapes but an arc is more complicated than a simple polygon.
Arc doesn't modify coordinates because an arc doesn't have a fixed size (it can be drawn as several segments). Modifycoordinates only works if the exact number of segments stays the same (and the segment types don't change). It doesn't destroy the path because it uses a common path, newpath() doesn't actually allocate a new path, it just clears a common one.

[rodizio]

Regarding the overclocking not increasing openVG performance:

Setting gpu_freq=400 and force_turbo=1 in config.txt sped up things quite a lot for me. Force turbo is important.

[rleonardi]

Hi,
Yes, I tried gpu_freq=400 and force_turbo=1 in config.txt and it really makes the difference.
Thanks

[rodizio]

Hey Paeryin, I've tried your openvg fork now. CPU load reported by top for my process went down from about 16% to 11%, rendering time (time measured from before Start() to after End() call) from about 55ms to 25ms.

More than 100% speed increase plus lower CPU load just by swapping the libraries, that's just awesome.