Category: Miscellaneous

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

>

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!

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

>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.

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

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

>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.

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

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…

>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.

>

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