Max Kosenko's picture

OpenVG Proposal

Hello all.

I know that it's planned to support OpenVG later in future. And that's ok.
But before that is done I'd like to propose some thoughts and ideas.

OpenVG 1.1 is nice open standard for 2D rendering engine.
It's main target mobile devices, but it's also declared for engine for device independent UI framework.

One of such framework is Flash and that's even declared in OpenVG 1.1.

But since we are all in .NET world - we have another alternative - XAML based UIs - WPF and Silverlight. WPF and Silverlight don't need any new frameworks, since Microsoft doing that by themselves, but Mono needs new modern UI Framework. GTK# is nice, Windows.Forms also. But all those are really old enough. It's hard to compare them with Silverlight/WPF UI stack.

WPF for Mono stuck somewhere behind just because it's too large project. But Moonlight is well in very active development. Moonlight main target to do Linux support for Silverlight, but we all know that after all difference in Silverlight and WPF not that large. And with Moonlight that becomes possible to make WPF-Like applications based on full Mono framework access.

But Moonlight problems in that approach are performance and multi-platform compatibility. It's right now using Cairo for drawing and already hitting a wall of Cairo performance which is not that good at all in software mode, and even with ability to change backends - there is no sign of ability to construct fast HW accelerated UI on Cairo. Also currently that leads to a lot of unmanaged code and related problems.

Idea is following: extend Open Toolkit to OpenVG + make Managed OpenVG over OpenTK.OpenGL/ES. That is shown to be possible in Amanith project, but it's native and closed source. Later that can be expanded with using very nice agg-sharp project which is 100% managed Antrigrain rendering engine - fast and very high quality. But on the first step it's just ok to use software renderer from OpenGL. Preliminary tests shown that even software renderer of OpenGL should be faster than Cairo.

As we all know - main driving factor of open projects is in their usage. I think that such approach can lead to creating fast WPF-like UI for Mono and Moonlight faster than Silverlight and Flash. And creating such strong UI Framework for Mono can bring more developers to Mono platform itself. Especially with the upcoming support for Mono development inside VS2010. And after all that can bring new contributors to Open Toolkit since it can become important part of Moonlight and Mono project.

What do you think about that?



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Max Kosenko's picture

I don't see any exactly same performance solution without code recompile with ifdef.
You're generating tons of overloads - that's pretty handy, but they all use after that delegate with native types...
Another problem is automatic fallback - in case no native OpenVG found - try to use type added at runtime that implements only minimal required set (no auto overloads) of functions.

I believe that should be done by adjusting generator and making more classes than it's with GL space:

Abstract class OpenVGBase with managed style methods to implement
Sealed class OpenVGNative : OpenVGBase - unmanaged style implementation
Public static API class OpenVG with internal static instance of OpenVGBase and generated mapping of static to instance calls.
+ Method on OpenVG to pass instance of OpenVGBase class - that is a place for injection of managed/unmanaged implementations

That way you will just add 1 virtual call and decouple OpenTK from any OpenVG implementations and can select independent implementation in runtime (inlcuding partial where some methods will throw NotImplemented).

That's not perfect solution. Just a vector to think.
Does that seems reasonable?

the Fiddler's picture

Damn, Firefox crashed and I lost my post.

In short: the many wrappers -> single delegate mapping is desirable. Better speed, faster startup time, lower memory consumption.

Delegates use native types; the wrappers perform all necessary marshaling (outside of strings). Better speed (absolutely no memory copying), more features (generics, which are not supported by the default marshaler) and consistency (the default marshalers on Mono do not play very well with multidimensional arrays).

Your design makes sense. It's clean and adds the cost of a single virtual call (OpenVG -> OpenVGBase). Note that even this approach wouldn't avoid the need for delegates in OpenVGNative: you'd still have to use function pointers for OpenVG extensions.

There are other potential approaches which could also work: I am toying with code injection in the delegates (can be used to perform error checking and improve startup time), but nothing concrete yet.

Max Kosenko's picture

Lazarus plugin in FF has saved me seeral times...

Well, may be something like generation of abstract minimal class + use of reflection for finding direct delegates in implementation types will be better approach. It would eliminate +1 virtual call and if you have managed type of delegates you can associate them with methods in reflected implementation.

zahirtezcan's picture
Max Kosenko wrote:

Abstract class OpenVGBase with managed style methods to implement
Sealed class OpenVGNative : OpenVGBase - unmanaged style implementation
Public static API class OpenVG with internal static instance of OpenVGBase and generated mapping of static to instance calls.

- IOpenVG instead of OpenVGBase (assuming this is possible that it is a C api)
- OpenVGNative : IOpenVG
- static VG class (need to find a better name)

static class VG<T> where T : IOpenVG
         private static readonly T implementation;
         public static void Initialize(T implementation)...
         public static void randomVGCall(params){ implementation.randomVGCall(params);}

AFAIK interfaces for generic parameters are just for binding and not virtual calls. Therefore, for each OpenVG function you need to generate that function in interface and static VG class, moreover implementors should implement it. If initialization of implementor with empty ctor is possible then use new() criteria on generic parameter and use singleton.

the Fiddler's picture

As an aside, Moonlight now has an initial OpenVG port. Pretty interesting hack.

Max Kosenko's picture

In case you're doing calls through interfaces - that is already +1 virtual call everywhere.
And also that way you're coupling things together because you have to follow interface requirements and implement all methods.
Some generator of stub class for managed OpenVG and runtime delegates creator would be faster and simpler to do.

Regarding OpenVG port. That's great someone decided to try. That is my primary intention. 10 fps much less than 315fps I have in SL3 cached mode, but I think there were no hardware use in that implementation. Reference Open Source implementation of OpenVG is NVIDIA work and it's known to be very slow and software only.

the Fiddler's picture

I think they said the OpenVG version was 10fps faster than the Cairo implementation, not 10fps in absolute values! The linked video runs pretty smoothly, nothing like 10fps.

Max Kosenko's picture

Sure, my mistake, it was 41 fps. That's a great news.

renanyoy's picture

I'm re-opening this thread, cause of last GPU for mobile (like ARM Mali-400 MP) implements the C version of openVG in hardware. I think this feature will be used in all new mobile device. so it would be nice to get a wrapper for it in opentk.

Inertia's picture

Excuse my ignorance, but could you please explain why OpenVG is more appealing to you than OpenGL ES? There's tons of devices with support for that available (and in the consumer's hands) already, and I don't see that Microsoft will care to support VG or ES.