I quickly ran head in first into OpenVG documentation, borrowed some code from mesa demos and ajstarks in another openvg thread. The code isn't horribly elegant yet, but should give some ideas to people who feel hopelessly lost. I promise i will clean it up at some point.
2 demos are now present at
https://github.com/kulminaator/rpi_open ... d_blockman
They are essentially doing the same thing, drawing a rotating and scaling snowman on the screen (right now the code is hardwired for 1280x720 resolution), one is using arcs and the other is using blocks. They also spill out the frames-per-second counter into the stdio (watching this over ssh is perhaps more reasonable than locally). As just drawing one snowman didn't put any pressure on cpu or gpu, i winded it up to draw 48 of them (2 paths, one big for snowman, one small for his hat). You can reduce the loop count to 1 of course, to see smooth movement at 60fps and almost no load to cpu and gpu.
My quick conclusions from this were the following:
good : openvg implementation does not seem bad at all, it may have some bugs around but i could easily top the gpu off with rendering commands for snowmen, yet the cpu was held at almost no load (roughly 4-6% cpu usage during the snowman and blockman).
good : memory usage of the application seemed to remain low, the paths are all stored in video memory ?
good: arc and lines appear to render at similar speeds
bad (?): 250 snowmen in a for loop seemed to choke the thing down to 5-7fps, depending on antialias settings, when i scaled it down the fps went up, so it sounds like a memory speed issue here, dont expect more throughput than 600-900 mbytes/sec (i estimated this on the size of the snowmen, count of snowmen drawn, fps and bit depth of the screen).
semi: reuse the paths, many OpenVG implementations are supposed to have path caches, i dont think RPI differs here (and also, it is actually comfortable to reuse them, if possible)
All in all, i think i seriously need to apologize for my initial statement somewhere in the forum here for underestimating the openvg and it's cause for existence. It seems to fill a slot pretty nicely in the embedded/low profile world.