>SpeedCrunch 0.10

>Earlier this week, SpeedCrunch 0.10 was released. Helder and all the other contributors have made a great job to make a good application even better. There are lots of new features, but some of my favorites are:

– The maths book, look up any formula and click it. Viola! It appears in your expression entry field.
– Automatic generation of a high contrast palette (this was alot of work for Helder). And it works like a charm.
– A reorganized, fresher looking user interface.

My humble contributions are the Swedish translation and a Windows installer. SC is available on all Qt-supported platforms, so there is no excuse for not using it. In fact, it is a really good example of a Qt project that is fully portable between all the supported platforms being built with CMake.

>Core Dump

>I have not been blogging the last couple of weeks, so here is a condensed report of what I’ve been up to.

  • Qtopia presentation at IT Universitetet, Gothenburg. Note to self, make sure to have water the first hour. Speaking for two hours, only sipping water the second half leaves you with a soar throat.
  • Work, work, work – I’ve been working like a mad man the last weeks. One week in Lapland doing winter testing for an automotive customer (great fun, but still quite a few days away from home).
  • Qt Quarterly dinner – a nice little event in Oslo. A rather loud restaurant, so it was hard to maintain a conversation, but still nice.
  • Carpenting – the upper floor is beginning to look ready-ish. Will try to get the wallpapers up this weekend. Then it is just the floor, doors and details left.
  • Driving – got my new car last week, a BMW 520d. It drives like a dream :-)

Well, now I need to work some more. Do not forget to watch the F1 next weekend. If BMW wins it must be due to my generous contribution. I hope that all the profit from my purchase is transferred directly to Dr. Thiessen’s department.

>Sharing files

>The news has mentioned file sharing more and more. The Pirate Bay has ended up in court, the Danes are blocking TPB and in GB, the discussing seems to concern shutting out customers (Swedish link).

Now, I have two questions:

#1 Will I be shut out for sharing my latest Kubuntu torrent?
#2 How do you discriminate between TPB and Google? Both allow you to search for copyrighted material.

Let me continue by saying that I’m not an information-wants-to-be-free-I-grab-what-I-can kind of guy. However, I feel that the current problem is a legal system and a market that are seriously out of synch with reality. Allowing this to ruin peoples lives and private economy during a transition period (yes – reality always catches up) is a Bad Thing.

So, what are the alternatives:

Watermarking (and prohibited/limited re-distribution)
Free (as in libre) software with paid services
Free (as in free beer) software with paid services
Free music with more frequent (paid) public performances
Paid software with hardware keys

I’m sure that there are more alternatives here. I will be interesting to see which is choosen as standard (hopefully now suing your customers…)

>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 :-)

>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