The Khronos Group - a non-profit industry consortium to develop, publish and promote open standard, royalty-free media authoring and acceleration standards for desktop and handheld devices, combined with conformance qualification programs for platform and device interoperability.

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

From my understanding now openvg uses opengl or openglES or qtopengl for implementation. Can we expect a dedicated hardware chip for openVg in future ? ( like opengl has) otherwise openvg can't make much perfomance gain than opengl . right ?

There are different levels of acceleration among those implementations:
- software rendering
- layered on top of OpenGL/OpenGL ES
- using 3D hardware directly
- using dedicated VG hardware
Each level offers different trade-offs.

I have one more question , please see it .
As we know there are many implementations . But in the the openVg specification says it is for Hardware accelrated vector graphics . So if someone implements it in software , there is no meaning right ?

Also i want know whether use the opengl implementaion will make some perfomance loss , rather than creating a new implementation directly for openvg.

I have one more question , please see it .
As we know there are many implementations . But in the the openVg specification says it is for Hardware accelrated vector graphics . So if someone implements it in software , there is no meaning right ?

OpenVG specifies a standard way for applications to access vector graphics functionality. This allows hardware acceleration, and it makes the lives of application developers easier. But even if you don't use hardware acceleration, you still have the latter.

Also i want know whether use the opengl implementaion will make some perfomance loss , rather than creating a new implementation directly for openvg.

Dedicated VG hardware may be more efficient than software rendering or 3D hardware doing the same task. That doesn't imply it's faster. "Hardware acceleration" can range from ultra low power SoC components to high end PC multi-GPU solutions.

From my understanding now openvg uses opengl or openglES or qtopengl for implementation. Can we expect a dedicated hardware chip for openVg in future ? ( like opengl has) otherwise openvg can't make much perfomance gain than opengl . right ?

Please tell your opinions..

Yeah, you're missing a couple.

The best of the commonly avaiable is the example from Hybrid's Rasteroid releases (http://www.hybrid.fi/main/download/tools.php). Simply download Rasteroid3 and use the EGL/VG/GLES dlls, libs and header files from that. It's much faster than the reference implementation (hundreds of times faster), and almost as accurate (some minor problems with linear gradients, and a few other things).

There is also AlexVG by HuOne (www.alexvg.com). They have an implementation, but their EGL is a bit off spec, and heavy use of their VG api will eventually cause problems too.

AmanithVG which you mentioned (http://www.amanithvg.com/) is fastest, but requires hardware support, and even then things like Radial Gradients is a bit off (on my computer at least).

Of the publically available OpenVG implementations though, I recommend Rasteroid.

Re: OpenVG - Implmentaion details..

AmanithVG which you mentioned (http://www.amanithvg.com/) is fastest, but requires hardware support, and even then things like Radial Gradients is a bit off (on my computer at least).

...

Hi Ivo, just to let you know, we have fixed radial gradients problems for Intel accelerators under Windows. If you want to test new builds you can contact me privately.
Unfortunately we don't have so much time to update the site and download sections; anyway as soon as possible we'll upload new AmanithVG builds, as well the new software rendering engine.

Re: OpenVG - Implmentaion details..

Originally Posted by muratmat

Hi Ivo, just to let you know, we have fixed radial gradients problems for Intel accelerators under Windows. If you want to test new builds you can contact me privately.
Unfortunately we don't have so much time to update the site and download sections; anyway as soon as possible we'll upload new AmanithVG builds, as well the new software rendering engine.

That's good to hear.

Since I made that bug report though I broke down and bought a video card (GeForce 7100 GS) so I could run it. This fixed weird artifacts I mentioned in the bug report, but I get a different issue now. When I rotate (or transform in general - with the PATH_TO_SURFACE transform) some geometry (any geometry - let's say a square block) with a radial gradient on it, I find the gradient starts swimming on me (the gradient moving in relation to the square). This should only be possible to do changing the paint matrix, but that matrix is still set to the identity the whole time.

At the moment, AmanithVG is an OpenGL (and GLES) based OpenVG 1.0 implementation. It's EGL-less, so, in order to have access to OpenVG functions, the user must open a valid GL context (using OS specific calls, or 3rd parts libraries like GLUT, or EGL, or ...) then call a proprietary function to initialize the VG context.

There are little limitations (eg: based on the number of available texture units). Please refer to this page for the complete list.
Anyway, the graphic board model doesn't matter, the important thing is to have working OpenGL (GLES) drivers installed.

Ivo: When you have the time, can you send me a little VG code snippet with your swimming radial gradient ? so i can check if the problem has been already fixed in the current AmanithVG version... mfabbri@mazat... (complete it)