moiji-mobile

Ever since the start of the Qt project I am working on DirectFB in Qt5 (and Qt4) with the remote goal of getting QtMediaHub to run. It started with catching up with the rather nice refactoring of lighthouse in Qt5, fixing memory and resource leaks in Qt5, DirectFB and mostly in the DirectFB lighthouse plugin.

It moved to dealing with broken “make install”, broken QML2 examples and documentation, figuring out how to get patches for QtV8/V8 into the project, adding MIPS code for the Qml mode (a new global object), global compare for MIPS and finally working on OpenGL integration for QML2.

In this specific case I had an OpenGL ES 2.0 library coming from a vendor and created the ‘directfbegl’ plugin to use EGL to go from IDirectFBSurface to an eglSurface. I think in this specific case there is unified 2D and 3D buffer space which should allow a lot of cool stuff.

It mostly works, QML2 has some way to go to work on battery powered devices but it is looking quite nice.

In general QPixmap is the class I dislike the most in the Qt graphics stack. It is not because it did anything wrong, or has annoying bugs. It is merely that painting on a QPixmap can produce a huge slowdown. Maybe it is even the immediate painting model I dislike so much.

In theory the QPixmap should represent the graphics memory and in theory painting this to another piece of graphics memory should be very fast. But reality is different, e.g. with directFB/X it is possible that your graphics memory resides in the host memory because you have allocated too much. X (EXA, UXA…) has migration strategies, directFB will just allocate it in system memory and it will stay there. So your graphics memory class might not be always allocated in graphics memory.

The athur painting capabilities of Qt4 were very nice but Hardware/X/directFB might not be capable of handling all the advanced concepts (perspective transformation, drawing other pixmaps scaled) and the paintengines then need to fallback into the raster path, but the raster path needs to work on a QImage and this is where stuff get terrible. There will be a download of the memory (slow), there might be a change in color (ARGB -> pre multiplied ARGB?), then the fallback, and then uploading of the memory again. So even classes like QGraphicsBlurEffect go through QPixmap -> QImage -> QPixmap (or at least used to).

So the basic problem with QPixmap and the immediate painting model is, only once you are done with painting everything, you know if starting with a QPixmap would have made sense. If Qt5 wouldn’t be all about OpenGL, I would have lobbied hard to make QPixmap an internal class and use it to ‘cache’ QImage that have peen painted a lot.

After all this love/hate with QPixmap there were still things I didn’t know. For Qt5 I am working on the directFB lighthouse plugin and started to work on make more tests pass. The thing I did not know was that by default the QPixmap has no alpha channel, only if either a mask is set or the pixmap is filled with a color that has an alpha channel the QPixmap will end up having an alpha channel and be ARGB. This means that a lighouse plugin providing a QPlatformPixmap implementation needs to be able to provide an ARGB and a RGB based pixmap and switch between them.

QT_QPA_PLATFORM_PLUGIN_PATH, QT_QPA_PLATFORM and QT_QPA_FONTDIR variables are used by QApplication/QPA to find the plugin. They are also available as arguments but there is no help entry for them (Qt5 needs some polishing).

When building a plugin and Qt insists to tell you that the plugin is not there, you are likely to have some undefined symbols, the best hint is to build your plugins with -Wl,–no-undefined in the linker line. Obviously we should plan to use dlerror to also report why Qt is seeing the file but not listing it as available plugin.

cheers