qt backend and backend selection

Registered by Jesse Barker

* Runtime selection of painter backend for qt
* Optimize existing OpenGL ES 2.x backend using NEON

Blueprint information

Jesse Barker
Jammy Zhou
Needs approval
Jammy Zhou
Series goal:
Accepted for 11.05
Milestone target:
milestone icon 11.05-final
Completed by
Jesse Barker

Related branches



[jazh Oct 22 2010]
Qt supports opengl, opengl es1.1, opengl es2.0 and openvg backends via QPaintEngine, and QRasterPaintEngine is the fallback implementation. The "Qt Graphics and Performance" series posted by QtLabs give good summary of Qt graphics system (begin with http://labs.qt.nokia.com/2009/12/16/qt-graphics-and-performance-an-overview/)

[jazh Oct 24 2010]
Use '-graphicssystem' option for backend selection when run qt applications (not supported for QWS). The values can be raster, openvg, opengl. But how to differentiate opengl and opengl es? Currently it is done when compile ('-opengl <api>' configure option, <api> can be desktop, es1, es2). So we may need to implement new QPaintEngine for opengl es1.1 and 2.0 separately to select opengl and opengl es bacekends at runtime.

[jazh Oct 25 2010]
Then how to handle same symbol for opengl and opengl es libraries if we implement different paint engines for opengl/es?

For another possible solution with only one opengl engine for both opengl and opengl es, there should be an API wrapper layer for opengl/es with a set of function pointers. And these function pointers are resolved at runtime based on the selected backend after check system environment (i.e, mesa opengl + hw accel opengl es -> choose opengl es). But actually opengl es1.1 and es2.0 are not interchangeable.

[JesseBarker Oct 28 2010]
Notes from UDS session
 * lets ignore GLES 1.1 -> not well supported
 * openvg still relevant (some customers)
     * symbian uses openvg, so the drivers might be stable
 * runtime selection of gl vs. vg -> available
 * runtime selection for gles vs. gl does not exist (compile time choice)
     * could be done in the same way, but applications that link against GL can cause troubles because the GL/GLES symbols are named the same
    * three cases:
        * application uses GL on its own
        * application uses GL via qt graphics system
        * application uses GL both on its own and via qt graphics system
    * runtime selection is tricky when applications uses GL and as the symbols get overloaded
 * graphicssystem could be chosen at runtime
 * Qt engineers currently oppose runtime selection except for NEON
 * Neon optimization with runtime detection has been implemented in Qt (not working yet http://bugreports.qt.nokia.com/browse/QTBUG-15150)


Work Items

Dependency tree

* Blueprints in grey have been implemented.