Accelerating Qtopia

Back to the Badge Qtopia screen driver project again. Using the svgalib based screen driver example, we’ve created a custom paint engine that intercepts all painting operations. By adding loads of qDebug statements I can get a (dead slow) driver that creates a log of exactly what takes place – a good basis for understanding what to accelerate and how.

Speaking of acceleration, the QScreen class contained some easy to reach methods: solidFill and blit. These map pretty well to the operations implemented in hardware – the problem with the blit operation is that the source image is located in the processors memory while the destination is in the video memory. This reveals the big engineering challenge here – the bandwidth between the video memory and processor memory is limited. This is really not an uncommon scenario, and often something that you choose to do. By not having the GPU and CPU sharing the same memory bus both processors can work independently without disturbing each other. The issue is just how to pass data between the two. (This is exactly why modern PC graphics cards have huge memories – to avoid having to pass textures and such over the PCI bus all the time).

Transformations

Running some of the Qtopia demos using the verbose driver reveal quite a lot about acceleration and what to avoid. For example, gradients, rotation and scaling will be hard to do something about – at least initially. Another though thing is painter paths...

Painter paths with gradient