[Development] OpenVG rendering backend to Qt Quick 2

[Gunnar Sletta]

On 18 Sep 2014, at 08:56, Mikko Hurskainen <mikko.hurskainen at nomovok.com> wrote:

> Hi,
> 
> I am interested on working on Qt Quick 2 Scenegraph OpenVG rendering 
> backend. Few embedded devices have both OpenVG and OpenGL accelerators 
> available.
> 
> There are few interesting use cases for embedded devices:
> * 2 display configurations, draw one with OpenVG and one with OpenGL
> * OpenVG consumes less power, draw some applications with OpenVG. For 
> example more complex idle screen.
> * Composite both OpenVG and OpenGL renderings into same display. Idea 
> here is that real-time critical items are rendered with OpenVG and 
> non-critical stuff with OpenGL
> 
> In Qt4 there was a OpenVG rendering backend, but that of course does not 
> fit directly into Scenegraph. Also I found that there has been a plan 
> for this kind of functionality in Qt Conference 2012, but I could not 
> find any results. Is there some (even partial) results available somewhere ?

Afraid not, the OpenVG based scene graph didn't go anywhere. 

> How about technical feasibility.

It isn't set up for it. It is supposed to be OpenGL based. There is an adaptation layer in there which you could hook into to try to replace the implementations of the default items. That layer also has the option of plugging in a different renderer which you would need to traverse the scene graph to do the actual rendering. You would also have to replace the render loop as this also assumes the presence of an OpenGL context. 

There has been some work ongoing lately to make plugging in an alternate backend easier though, partially based on some talks at QtCS earlier this year about making the scene graph available for non-GL chipsets. 

> Scenegraph type rendering is in general 
> doable with OpenVG. The backend would need re-implementation to use 
> OpenVG primitives instead of OpenGL (ES). In general I think it should 
> be doable. Any opinions or possible pitfalls ?

Parts of the public API dictate OpenGL, like the material API and the GeometryNode, so anything using that API wouldn't be supportable. Particles would probably not work and ShaderEffect would naturally not be possible. 

> 
> With Best Regards,
>  -- Mikko Hurskainen
> 
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

cheers,
Gunnar

www.sletta.org