QPixmap and what I did not know

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.

GNU Smalltalk deployment with images and image resumption

Once up on a time I was sitting in a cold hall at the Barcelona exhibition ground, a power outage has taken down several DVB-H platforms (racks consisting of servers, streamers, RF equipment...) and once power was restored red LEDs were blinking, systems not coming up automatically, hordes of engineers trying to boot the right kernel, trying to remember the multicast routes they had typed in by hand, chaos, hectic. It was interesting to witness that as we could lay back, continue with our work, as our platform was configured to come up automatically and it did.

One has to assume that stuff breaks, software, disk, RAM, CPU, power supply, anything. The only answer to that is be prepared, build your software to deal with failure (or nicely try to restart), make sure all systems start automatically, have backups, have a plan.

For my GSM (telephony) in Smalltalk components I didn't do that yet, mostly because my code was not very mature, I was still building up the trust relationship and so my deployment consisted of manually running GNU screen, then GNU Smalltalk, manually loading my code, starting things up. It was about time to correct that.

The tool of choice is the gst-remote application, it will run a GNU Smalltalk image, it can daemonize and it will listen for input from other systems. While moving to this deployment my fellow Smalltalkers were kind enough to fix some bugs on the way. There was an issue of gst-remote exiting when saving an image, the Delay class not functioning properly on resume, the wrong FileDescriptors being closed on image resumption. It is very nice to get help that fast!

My deployment now consists of building GNU Smalltalk packages, having a Smalltalk script to load the package and call start method of that package followed by taking a snapshot and exiting. I can then resume the image and if the software is prepared to deal with image resumption it will work.


Eval [
| name image |
name := Smalltalk arguments first.
image := Smalltalk arguments second.

(PackageLoader packageAt: name)
fileIn;
start.
ObjectMemory
snapshot: image;
quit.
]


Qt, QPA and some notes to myself

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