views:

1147

answers:

0

I'm currently trying to get OpenVG up and running on my desktop. The problem comes here: I am / will be developing an application for a Windows CE device (with .NET compact framework), which has hardware-accelerated OpenGL ES 2.0 and OpenVG 1.0.1 (based on TI OMAP35x, if you're interested). The application will definitely use OpenVG for drawing, and likely OpenGL for some effects if OpenVG doesn't offer them (i.e. blur).

Now I'd like to develop on my desktop without the emulator (see this question). So I thought I just import OpenVG with P/Invoke, which was quite easy, since the OpenVG people made their constants into real enums, and though a procedural C API, it translated very well into an object-oriented form (with a Graphics class for drawing and Path, Paint, Stroke and Image objects). I also managed to get going with differently named DLLs and entry points. Oh, and I imported EGL 1.3, also quite easy to translate to an object-oriented API.

Until this point, it sounded quite good. I thought I'd just use the OpenVG reference implementation from Khronos, but it is slow. Really slow. You know, like clearing the surface taking literally a second! So I thought, fine, OpenVG is a standard, I'll just take one of the other implementations. Most of them are based on OpenGL, which is what I want. Or isn't it?

No, it's not. Creating an OpenGL ES 2.0 surface with EGL 1.3 (supplied with the PowerVR Windows Emulation SDK for OpenGL ES 2.0) is not compatible with any OpenVG implementation I tried. Some of them require traditional OpenGL (AmanithVG GLE), the EGL version supplied by PowerVR doesn't support OpenVG. Most implementations don't even have EGL and use some bizarre functions to initialize the context - all of them assuming that an OpenGL context has already been created. OpenGL, not OpenGL ES. Sigh.

The only one I could get to work was AmanithVG SRE, which is very fast for a software implementation and does not rely on OpenGL or EGL. It works, but it is still far too slow for real time animations.

I can't believe that these things feel so wrong. I'm really tempted to just use WindowsMobile.DirectX.Direct3D, for which PowerVR supplies an emulation layer for Desktop Windows, in the hope that the final Board Support Package will supply Direct3D as an OpenGL ES wrapper, like it seems to be on many devices.

So, the question, finally:

Is there any OpenVG implementation for Windows Desktop systems that works with OpenGL ES 2.0? Bonus points if it works smoothly with PowerVR's OpenGL ES 2.0 emulation and the supplied EGL 1.3.

Or should I just try to use a traditional OpenGL 2.0 implementation on the Desktop? But they're typically not supplying EGL as well. I don't want to have two initialization layers (EGL and WGL). Or should I?

Note: this is not a .NET question, because the problem is the very same without .NET.