Badger

We're showing Badger at the Elektronik-EP fair for three days. You can find our booth here, and print a free ticket here.

And, by the way, congratulations to Nokia and Trolltech!

Shameless stunt

Anyone in western Sweden looking for a nice car. Look no further than this lovely vehicle! I can throw in a copy of Foundations of Qt Development to sweeten the deal :-)


Yes - I'm getting a new car. The old one has been used as a commuting car, so just "kind" kilometres. The reason I'm changing is because the Passat is a leasing car. I'm very happy with it still. Get it while its hot! :-)

Embedded is fun!

The Qtopia+BADGE study has really reached its end. It has been really fun working with low-level Qtopia development for a few weeks. I’ve not done all this alone, both Bitsim Stockholm and Gothenburg have been involved. Lot’s of colleagues have been forced to put up with my Qtopia ramblings (yes, I’m obsessed) and I’ve had the opportunity to have a look at some really interesting parts of Qtopia.


The next step here is creating a product, polishing the driver. Something that I’ve learned from working with software is that the 80-20 rule aught to be called the 90-10 rule. Since the work until now was the first 90%, we’ve probably spent 10% of the time – meaning lots of more Qtopia work for me :-)

For those of you who are curios, you can find BADGE information here. If you happen to be in the vicinity of Gothenburg or Stockholm, do pop-by and I’ll show you a demo. You can reach me at e8johan -at- gmail -dot- com.

Look - it moves

Today is ugly-hack day. BADGE has a nice feature that has no real counter-part in the Qtopia API. This means that I have to dynamically cast the painter engine for a given widget and provide some additional methods in the BADGE version.

The feature of the day is to integrate a live video stream with the Qtopia interface. BADGE supports video through “blue screening”. This means that a given colour is replaced by the video stream. The video itself can be translated and scaled, making it possible to have BADGE put video in a moveable, resizable window – but let’s not get carried away.


Using just a few lines of code, we can get a video stream into the user interface. All is handled by the BADGE hardware – remember that our CPU is running at 180 MHz and uses a 60 MHz bus to access the BADGE GPU so we cannot handle it through it. The video below shows the video running together with Qwt. The video quality isn’t really HDTV – I only had a mobile phone to film with, but it shows the principle.



So, it seems that it is fully possible to accelerate Qtopia using BADGE. Actually, it was easier than I first expected. However, it is far from possible to accelerate everything – at least with a reasonable effort. IMHO it seems more efficient (man-hour-wise) to provide a clean acceleration driver and write one’s applications with care than to spend man-years creating an overly complex driver. Having discussed this work with Trolltech, it seems that Qtopia 4.4 will have even more accelerateable features – I’m looking forward to it :-)

Please Ignore

Note to self...
Doors: Addera vit, 82cm
Handles: Hoppe Verona

Accelerating Shapes

Since BADGE supports quite a few of Qtopia’s basic shapes, we’ve spent some time implementing everything we can think of. Combining this with the verbose driver, we can also tell exactly what the problem is. There are lots of rocks to turn and quite a lot of easy to reach fruit. However, the purpose of the work (for now) is really to do a feasibility study and to lay down the foundation for future work. I interpret this as show that acceleration is possible and pays off, but don’t fix all the details right now.

One frustrating part right now is that the Qtopia demos from Trolltech tend to use quite a lot of complex features to get cool looking graphics. This can be accelerated, but one has to be aware of how things work. For example, when using gradients and painter paths it is always good to pre-render this to a QPixmap and then blit it repeatedly to the screen. This keeps down the data transferred pixel-by-pixel between the CPU and GPU as we can buffer pixmaps in the graphics memory and blit them by passing a few control bytes between the processors.

The good news is that we can see a real increase in performance when accelerating operations. The problem is really the huge wealth of combinations available. Looking at the svgalib-based the driver we can see that the ability to accelerate depends on a number of parameters:

• pen – keep it simple, one pixel wide.
• brush – simple solid fill, we do support transparency, but not gradients and such.
• transformations – stick to translation. It would be possible to scale some shapes, but not pens unless they are decorative (i.e. always one pixel wide).
• clipping – clip to a single rectangle. This means that you have to avoid having rounded corners on your windows. (Our driver actually cheats and uses the boundingRect of the clip region – dangerous but rewarding).
• aliasing – avoid anti-aliasing, it makes things difficult. For example, we need to ensure that BADGE and Qtopia uses the same anti-aliasing algorithm.
• composition mode – complex blending is supported by the BADGE blit engine, but we’ve not spent time to let Qtopia utilize this.

No screenshots today, but I can tell you that I’m compiling Qwt right now.

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

QtCentre - Providing Answers for Two Years

Two years ago the QtCentre site was launched. The goal was to provide the leading forum on the internet, encouraging the exchange of experience and to provide a meeting point to the Qt community. The response to this has been beyond our wildest expectations - all thanks to all our visitors and contributors.

As a part of QtCentre's ambition to be the meeting point of the QtCommunity a Qt programming contest was held last year. The result was fenomenal with a great list of high quality entries and a matching list of prices. The participants came from all of the earth, reflecting the wealth of the community available at QtCentre.

A forum is good for exchanging experience and providing answers. For the more in-depth information QtCentre provides a wiki filled with articles. These articles touch the peculiarities of Qt, provide helpful tips and tricks as well as providing useful general knowledge about Qt.

The QtCentre team would like to thank all visitors and contributors. Thanks to you, the centre has succeeded beyond our wildest expectations. We hope to see you all in 2008 and make that an even greater year!


QtCentre is the leading independent Qt forum. In addition, it hosts a wiki filled with in-depth Qt articles. The goal is to provide the Qt community with answers and information.

The QtCentre is based on the vibrant community surrounding Qt. The centre is one of the few sites actively used by both the open source community and the propritary users of Qt.

Badger - again

Getting Qtopia up and running on the BADGER board was really just a matter of compilation. However, Qtopia’s built-in framebuffer driver automatically assumed that 16 bits per pixel was a 5/6/5 format. This resulted in some rather funny looking colours as it works with a 4/4/4 setup – but at least the framebuffer works as expected.

Even if BADGER works with 4/4/4 right now, it can easily be reconfigured and synthesized for pretty much any other conceivable pixel formats. However, the standard reference design uses 4/4/4 right now, so I'll work with that.

Spending a few more hours, an unaccelerated driver operating directly on the screen was created. The driver simply provides a screen class initializing the hardware, a dummy surface and a paint device simply returning a paint engine inheriting the QRasterPaintEngine. By implementing the drawBufferSpan and drawColorSpans we get something on the screen.

And, hey, the drawColorSpans is a simple draw-horizontal-line-function so we can accelerate it right away. The drawBufferSpan is also accelerated – we simply plot the data to a buffer in the video memory and then use the blitting capabilites of BADGE to have it handle the alpha blending – neat :-)

Badger

Recently I’ve been working with Qtopia for Bitsim. The plan is to support acceleration through Qtopia on Linux when using their graphics controller BADGE. For those of you interested in hardware, BADGE is an IP-block that can be implemented in both FPGAs and ASICs. It offers a basic framebuffer as well as acceleration of basic shapes such as lines, rectangles and text (!). It can also be used for blitting and such. You might know it from an apperance at LinuxDevices.

Anyway, the correct work is being made using the BADGER reference board. It offers a 180 MHz ARM9 CPU and an FPGA holding BADGE operating at 100 MHz. These are interconnected using a 60MHz data bus. Not too much power or bandwidth, so it will be interesting to see what kind of performance we can get from it. The screen used is an 800x600 pixels TFT – quite a few pixels per megahertz compared to other reference boards I’ve seen. The BADGE hardware can be tuned to support different bit-depths, but right now I’m working with a 4/4/4/4 configuration (four bits per color and four alpha bits).


The BADGE GPU can be reached through a library and a custom Linux framebuffer driver. The idea is to have Qtopia use this library through a custom QScreen class. I’ll also have to come up with a custom QWSWindowSurface, a QPaintDevice and a QPaintEngine.

2008

First if all - happy new year to all of you! 2008 will be a great year with lots of exiting Qt and KDE news. The biggest will probably be Qt 4.4 and KDE 4.0 - two milestones.

For my part 2007 was the year when working with Qt became a reality. My book, the Foundations of Qt Development, was printed, I visited DevDays, I started laying out slides for training based on the book, I had the opportunity to work within a Qt project as well as an adviser to a Qtopia project. All in all great fun!

2007 was also a year when I ran out of time. This is a rather nasty experience - finding that you have more to do than you can do in 24h/day. Reaching the conclusion that it isn't you (or in this case me) but the amount of work is really hard - but having that revelation really helps. For example, I still have not posted any pictures from DevDays here. Luckily, I've had the chance to delegate things both workwise and in the community - but it is really though releasing a pet project and letting some one else in, but it is all for the better. In December '06 I made the decision to step down as maintainer for SpeedCrunch - and during 2007 Helder Correia has really turned up the development pace and revitalized this project. Great work!

So, for 2008, there are lots of exiting news. First of all, our family will have a new member, going from two to three. It will be very exiting. My employer, Bitsim, will start demonstrating Qtopia with our own graphics controller. I will try to run a few Qt training sessions based on my book (interested? - contact me! my personal goal is three sessions next year). I will also try to blow some life into my mouse-gesture-recognition package.

Let's see what I actually can find time for. Some life-changing events are approaching, so it is really hard to say what the outcome will be - other than exiting and great fun. The sum of all this - I'm convinced 2008 will be a great year!