I’m trying to display some OpenVG stuff on an X-window. The X window gets created, but for some reason the output remains black.
I can successfully clear the screen which causes the background color to change; but as soon as I try to draw anything (even a small line) the entire screen turns black. Could anybody help me understand what may be causing this behaviour?
I’m trying to use the ShivaVG software implementation for OpenVG, along with the Mesa3D library for OpenGL and an EGL implementation for GLX.
One important point is that if I make only OpenGL calls in my application, the output is seen successfully in the X window.
I have set the “EGL_RENDERABLE_TYPE” attribute to “EGL_OPENVG_BIT” when choosing the config.
Also, I have called the “vgCreateContextSH” api in the beginning as required by ShivaVG.
Any help anybody can give will be much appreciated.
My understanding was that ShivaVG was built completely on top of OpenGL, so you should have no need for EGL. I’m guessing your window creation is getting mangled by mixing contexts/surfaces. Have you tried using glut to create a window, then creating the ShivaVG context?
You’re right, I don’t really need EGL in this case because I’m independently creating an X window and trying to render into it. But I want to retain EGL so that I can completely remove all X window creation calls in future and make my app independent of the windowing system.
Also, I think your guess about mixed up contexts and surfaces is spot-on.
What would probably work best for me is to have an EGL implementation that supports both OpenVG and OpenGL-ES as the client API. This is almost the exact same requirement as posted by Ajay in his 2nd question here.
But I tried a few experiments thanks to which I know a little more. I can successfully change the background color to whatever I want.
But the area on which OpenVG tries to render becomes black.
If you look at the attached image, I can change the white background to any other color; but the black rectangle stays that way. The black rectangle is actually the OpenVG drawing area, which I have scaled down to be smaller than the window.
This may be difficult with ShivaVG as it requires a desktop GL context, it is not implemented as an EGL client API. Which means, there is no integration between ShivaVG and any existing EGL implementation that I’m aware of.
Indeed that would be the ideal solution, but keep in mind, an implementation of either client APIs must be written for a particular implementation of EGL. The EGL specification does not define a common interface between the client APIs and EGL.
His question was based on using an EGL based openvg implementation with opengles, ShivaVG does not fall into this category.
By the looks of it, I would guess you’re creating a window with glut, then creating an egl window surface. Assuming when you say OpenVG you mean ShivaVG, then as previously mentioned, any ShivaVG calls will render to the desktop GL window, and not the egl window surface. If you’re goal is to be able to render to the same surface using ShivaVG and OpenGL, don’t use EGL. If your trying to use EGL for portability purpose, you won’t be able to using ShivaVG without either porting it to opengles, or using some hack for window creation which would not be portable.
ShivaVG doesn’t triangulate paths; this library performs non-simple, concave, holed, … polygons rendering using this stencil buffer tecnique.[/quote]
That’s pretty cool, it’s been a pretty hot topic lately in relation to acceleration of openvg using the 3d pipeline.