Features on OpenVG next Releases

[ioseph_martinez]

I would also use this thread to gather any ideas or suggestions or features you would like to see on the coming releases. No promises they will be included but definitely will be considered.

This is the list of features on the next releases of OpenVG for Vybrid from Freescale.

It may change, but is the plan so far...

Release 0.5.0

1. Support MQX 4.0.2 Alpha2 (on TWR and AutoEVB) and 4.0.1 Beta3(on TWR)

2. Redefine the API architecture

1. make MQX_template_list available to the application
2. add fbdev abstraction on DCU
3. write simple “fbws” window system on MQX to support EGL window surface
4. make eglfsl private extension obsolete

3. Merge vivante 4.6.9p11 release

4. Enable openvg trace info for debuggin

Details on future releases are just general:

Release 0.6.0

- Conformance Test Compliance

Release 0.7.0

- Performance Improvements

Message was edited by: Ioseph Martinez Pelayo

[jasonwilliamson]

We are currently using the eglfsl extensions in eglfsl.h.  Is item 2.4 above intended to remove the eglfsl.h extensions entirely?

[ioseph_martinez]

To be honest I don't know the details but we should be able to provide a different mechanism to provide a physical address to the DCU Layer to point to the rendering buffer.

I think that is on points 2.2 and 2.3 write simple “fbws” window system on MQX to support EGL window surface

Feng Wei, can you confirm this is true?

[jasonwilliamson]

We need more than the physical address of the surface buffer.  We need the stride, height, and color format as well.  This is important for setting the DCU layer registers.  It's also important for buffer synchronization when double-buffering the surfaces.

We've tried using our own internal calculations for these values, but that causes problems every time the OVG driver is updated because there have been changes to surface stride and height requirements.  Also driver may create a different OVG format identifier than we assume.

[fengwei]

EGL has three kind of surfaces support: Window Surface, Pixmap Surface and Pbuffer Surface. Window and Pixmap Surfaces are native display system related. That's why in 0.5.0 DCU is hidden behind the EGL and application could ignore display details and just use eglSwapBuffers to have VG render buffer displayed.

There's quite a lot of driver code in EGL and HAL levels to handle display system stuffs, so for special use case from yours, I think we could make a tiny driver that be display unawareness, and only keep Pbuffer Surface. If you agree, I plan to add one build option to generate the tiny driver for you in release 0.6.0. Before that, I will just provide a patch on 0.5.0 to make your program work, after Ioseph verifies it.

[ioseph_martinez]

eglfsl will be removed in the future because it will be not necessary anymore with the new native window system being created: FBWS on 0.5.0

According to R&D, pixmap can be used to gather the required information to configure the DCU and the effort to port the code to use pixmap should not be complex.

The plan so far is just making it obsolete so we will not remove it until you are fully migrated to the latest new release.