If you play games like Rainbox Six: Vegas or watch movies like Elephant Dream, you will notice the use of the so-called Bloom effect. In fact, Vegas is so bright and surrealist that this game becomes known for its Bloom overuse.

In this Graphics Dojo example, I would like to show how to render an image with the Bloom effect. This extends the previous example from Zack on making real-time glow effect. The technique: create a copy of the image, blur it, increase its brightness and then combine with the original image with a certain composition mode and opacity. Since a picture is worth a 2^10 words, I will let the following screenshot (click to enlarge) speaks for itself.

The image on the left side is the original, whereas the right one shows the result of applying Bloom. As you can see, there are few sliders where you can tweak the parameter to achieve the effect that suits your taste. Different composition modes can give (not so radically) different results as well, just play around with it.

How to get it? Just do “svn checkout svn://labs.trolltech.com/svn/graphics/dojo/bloom” followed by the usual “cd bloom && qmake && make && ./bloom”. Once the main window shows up, you can also change the image by using drag-and-drop from a file on your disk or even a link from the web browser (e.g. straight from your Flickr gallery). Have fun!

To breathe some new life into the graphics dojo, here’s an example of how to put widgets on top of an OpenGL scene using QGraphicsView. By leveraging the synergy (tounge in cheek) of the OpenGL module and graphics view’s in 4.4 new widget capabilities, the long lacking feature of putting widgets in OpenGL becomes possible. All that’s needed is to set a QGLWidget as viewport on the graphics view, override QGraphicsScene::drawBackground() to do the OpenGL rendering, and add widgets and other graphics items to the graphics scene as usual. The result can be seen in the screenshot below, which shows a simple obj-model viewer application written in just a couple of hundred lines of code:

The source code is available by “svn checkout svn://labs.trolltech.com/svn/graphics/dojo/modelviewer”. Have fun!

The Wide Finder Project is an informal parallel programming competition where the task is to compute web site statistcs from a 218-million line access log. Each entry will be benchmarked on a Sun T2000 with support for 32 hardware threads, giving lots of opportunities for parallel processing.

What makes this really interesting is that the project is not only about performance, but rather about writing code that scales to many CPU cores with as little extra programmer effort as possible. Some results are already in, with OCaml currently in the lead performance-wise.

Each log line looks something like this:

www.example.com - - [17/Jun/2007:21:37:17 -0700] “GET /ongoing/ongoing.atom HTTP/1.1″ 304 - - “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

Eager to bring the performance lead back to C++ where it belongs I started out writing my own implementation using QtConcurrent and the other Qt APIs. Briefly explained, the code uses QtConcurrent::mappedReduced to multi-thread the code, and then QByteArray::split() twice to iterate over each word in each line. The current version computes the number of hits for each page.

Results: (parsing 100K lines on an 8-core 2.8 GHz Mac Pro)

1 Thread
real 0m2.283s
user 0m1.141s
sys 0m0.249s

2 Threads:
real 0m1.446s
user 0m1.853s
sys 0m0.271s

1.6X speedup.. not too bad.

4 Threads:
real 0m3.186s
user 0m10.643s
sys 0m0.407s

1 second slower that the single-threaded version.. this does not bode well.

8 Threads:
real 0m7.000s
user 0m46.922s
sys 0m0.724s

Seven seconds! We get a nice linear scaling of the run-time as we increase the number of threads, but unfortunately in the wrong direction. The program us spending a lot of user time doing something though, so let’s run it through Shark and see what’s going on:

80% in a spin-lock used by malloc/free. But who is calling malloc that much?

Aha.. QByteArray::split(). While being a very convenient API, split() was clearly not designed for heavy parsing like this. Still, I’d like a less catastrophic impact on the run-time when adding threads, even if the program really is calling malloc/free to often. Let’s try with the ptmalloc memory allocator instead:

8 Threads:
real 0m0.908s
user 0m3.784s
sys 0m0.533s

ptmalloc is used in GNU/Linux though the GNU C library and scales much better on multicore systems. The program itself still does not scale beyond 4 threads, but it does not get significantly worse either when adding threads. I guess it’s debatable whether or not this is qualifies as a bug in the Darwin memory allocator, but at least ptmalloc shows that it is possible to do better.

That’s all for now For the next installment I’ll try to get better scaling, at the expense of increasing the developer effort.

After many moons, I have started to work again on my personal project, Gutenbrowser. It is in need of much maintenance and love.

Since Qt finally has a good webview, QWebView, I can finally start working towards version 1.0! With very little work, gutenbrowser can now show Gutenberg Project etexts that come with images.

Since I have a macmini at home, I can distribute Mac binaries, as well as Windows and a few Linux embedded devices (Openmoko Neo and possibly Nokia’s n8×0’s Qtopia )
and with the help of Petter Reinholdtsen, fix a few bugs and be in the standard Debian distribution.

For those that do not know of the Gutenberg Project, there are over 25,000 free books available!

Intro

Hello! I have something to show you. I’ve been working on a tool that teams up with Doxygen to produce .qch files (Qt Compressed Help) for use with Qt Assistant from your code documentation - a feature that has been asked for repeatedly since 2003 ([1][2][3]..). In this post I will introduce doxygen2qthelp, the answer to your request.

Download

You can grab the current code from our Subversion repository like this:

Building

I should mention doxygen2qthelp requires a Qt version later than 4.4.0, which at the moment means a snapshot of 2008-04-24 or later. If you start building now be sure to configure with -assistant-webkit. More about this later.

Background

Doxygen has been able to produce .chm files (Compressed HTML) from properly documented code. To be precise Doxygen does not create the .chm files itself: instead it produces a bunch of files that are used to instruct the Microsoft® HTML Help Compiler (hhc.exe). These three files contain the table of contens (file index.hhc), the list of keywords appearing in the index (file index.hhk), and a project description (file index.hhp). The former two of these are written in some form of "perverted HTML". What doxygen2qthelp does: take these files, parse through the soup, and create a ready-to-go .qch file for viewing in Qt Assistant. Alternatively, a fine-control .qhp file (Qt Help Project) can be produced.

Usage

Let’s say you were the author of the QWT library and you felt like shipping .qch files of your documentation. What would you do? Let’s first look at a manual approach, and see what we can automate after.

1. Enable Microsoft® HTML Help output
   First you need to tell Doxygen to generate HTML Help output. To do that you enable GENERATE_HTMLHELP
   GENERATE_HTMLHELP = YES

   in the Doxyfile. Without HHC_LOCATION being set Doxygen will just produced the index.hh* files and not try to call the Help Compiler from Microsoft®. That’s just how we like it, especially on our Linux Machine.

2. Run Doxygen
   If everything went smoothly we should have both HTML documentation and the index.hh* in doc/html/ .
3. Run doxygen2qthelp
   Now doxygen2qthelp comes into play. Invoke it from the QWT source folder like this:
   $ doxygen2qthelp --namespace=net.sourceforge.qwt --folder=qwt-5.0.2 doc/html/index.hhp qwt-5.0.2-doc.qch

   Alternatively you could also write this calls information into an .ini file and invoke it like this:

   $ doxygen2qthelp --config qwt.ini

   -- qwt.ini --
Namespace = net.sourceforge.qwt
VirtualFolder = qwt-5.0.2
InputFilename = doc/html/index.hhp
OutputFilename = qwt-5.0.2-doc.qch

4. Enjoy
   Open the documentation in Qt Assistant, preferrably a version from Qt 4.4.0 or later configured to use Webkit in Assistant (./configure -assistant-webkit). Without Webkit parts of the Doxygen HTML will look quite messy.

Automation

Wouldn’t it be cool if we could teach Doxygen to call doxygen2qthelp for us? Good news: I wrote a patch against Doxygen 1.5.6 for you (see doxygen_patch folder). Dimitri van Heesch and I planned to integrate that patch upstream for one of the next Doxygen releases.

1. Apply the patch and rebuild Doxygen
2. Add a few lines to the Doxyfile:
   ## Paths Relative to the 'html' folder!
GENERATE_HTMLHELP = YES
DOXYGEN2QTHELP_LOCATION = doxygen2qthelp
QTHELP_CONFIG = ../qwt.ini
QTHELP_FILE = ../qwt-5.0.2-doc.qch
3. Run Doxygen

That’s it - a single call to Doxygen can now produce .qch files.

Final words

Please report any bugs you might find through the Trolltech Bug tracker. Feedback is also welcome. Thank you!

Well,
I start work for a different company today, namely Nokia. Perhaps you have heard of them? No? Well, they used to make rubber boots but now make phones. Lot’s of them. They have a few employees. Lot’s of them. and now, a few more, thanks to the (more or less) peaceful assimilation of Trolltech.

Am I worried? A bit. The management structure at Nokia is overbearing, not like Trolltech’s lean and mean machine. I doubt I will see the CEO of Nokia getting drunk and wrestling with engineers any time soon. I doubt I will ever be called to a meeting with him to pick my brain about community matters, much less even get an email from him. I liked that about Trolltech. The openness, the friendliness.
Hopefully my boss will stop wearing his shoes so much. He used to go barefoot a lot more than he does now. I liked that about him.

Today, I start work for Nokia, sitting in the same desk (I hope), loging into the same machines (I hope), and continuing my work from yesterday (except today is the BBQ beer fest.. wweeeeeeeeeee!), on the Qtopia SDK, on the n8×0 and Neo devices. I still get to work with the greatest multi licensed cross platform toolkit ever - Qt. I get to use the greatest and Kool Desktop Environment - blackboxqt! heh and also - KDE.

Best of all - I get a new phone and some Nokia schwag.

I, for one, welcome our new Nokia overlords!

Well,
This is my last post as a Trolltech employee. I have worked for Trolltech Pty Ltd, in Australia. since 2003. I can proudly say I helped Qtopia become more open, and fully GPL. It’s been a short 5 or so years, I have seen the Brisbane office grow from around 14 people to around 50, found my wife, had a son and daughter. A lot has happened in the past years. Ran ‘make’ more times that I want to think about. Got Qtopia running on all the devices I could. Yelled and complained and praised till I was blue in the face.

Tomorrow (Tuesday), I will be employed by Nokia, doing the same things I did today (well, maybe the day after next, tomorrow is the obigitory write-off “1st day”, BBQ and beer drinking).

It will be a challenging year ahead, I am sure both Nokia and Trolltech ^H^H^H^H^H^H^H^H Qt Software have things to learn from one another. I am personally wishing Trolltech’s seeds of open source will blossom Nokia into a greater thing.

So tonight, while I am unemployed, am going to live it up! and… uh… well… write some code (having small kids really saps your energy) and get more familiar with scratchbox2. (which thankfully uses a real cross toolchain).

I feel it is a bit like Christmas… So, if you talk to a Troll today, shake his/her hand and tell him/her thanks for making the world a more peaceful place.

As many of you know, I’m an OpenDocument fan, I love working on making KOffice rock, which is something I do at every opportunity. The work I do is mostly outside of the KOffice repository nowadays and others are picking up the slack. One really cool development is that I found some people willing to put some corporate funding into making our ODF compliance rock!

If you want to write some software and you want to maintain it for various years the best way to do this is to have regular testing in place to ensure that with further development the features you released in a previous release didn’t break. This is a common practice and the quality of your release is directly linked to the amount of testing you do. In the open source world the many users tend to work as testers, which is a concept that generally works pretty well. A much better solution is to have auto-tests. This is basically a program that does a certain task and checks the outcome for the expected values.

In KOffice we are working on improving out ODF compliance by first writing a test, and then making sure that the feature gets implemented. Before committing all tests ever written are ran and only when all of them (still) pass we can say the new feature is done. It should become obvious to anyone reading this that writing new software like this will create better software that is easier to maintain over time. Especially in open source where new people come and go on a regular basis.

I’m therefor extremely happy to report that Girish Ramakrishnan has so far created and made passing 51 61 OpenDocument Format loading tests. This in effect means we have lots of ODF features we researched what they should do (by reading the ISO specification) and then make sure we actually do that. Now and years from now they will do what they are meant to do.

The features we are testing are, for example, lists. That a document that is meant to have a numbered list with any sort of complex numbering load and show correctly. But sometimes we have some quite different test, things that KOffice never did before. In that case new features have to be added to KOffice. One such feature is the dropcaps. This is a feature that people that write newspaper style documents will love. Let me show a screenshot which explains it best.

For this new feature we have yet to add some dialogs to configure this, so to try it out I started OOo and loaded the odt doc in KWord. Which I admit is a pretty cool way to show how far we have come in the interoperability area

Update; updated number of passing tests.

So the time is finally here. Qt 4.4.0 was released a few weeks ago and as promised Qt Jambi is right behind. A lot of effort has gone into this one, in addition to supporting all the new Qt features, like Phonon, Webkit, Widgets in Graphics View, XQuery and Qt Concurrent, we also have a seriously improved deployment system, JDBC support and a compile-time checked signal-slot approach for the paranoid. Its a good time to be a Java developer I tell yah! We already mentioned all the featuers in the Qt Jambi 4.4.0 Preview Blog so we won’t repeat ourselves here… (There is a danger in linking to eskils blog, as it links to others again, which again links to others, which in the end proves to be a fairly complex graph, but then again… we are engineers and like that kind of stuff)

Under the cover we’ve also done quite some work. We also did an overhaul of the garbage collection and memory management subsystem and hopefully ironed out all the bumps and dents. We’ve also done some work on the build system, so that our users that build from source have a bit more substantial buildsystem to work with. Previously it was a complex install document, which has been replaced by a simple ant command which just does it all… I was very happy to see that the deployment system & ANT build scripts works well enough for the webstart to look like a plain, normal webstart app:

<resources>
<j2se version="1.5+"/>
<jar href="qtjambi-examples-4.4.0_01.jar"/>
<jar href="qtjambi-4.4.0_01.jar"/>
</resources>

<resources os="Windows" arch="x86">
<j2se version="1.5+"/>
<jar href="qtjambi-win32-msvc2005-4.4.0_01.jar"/>
</resources>

No magic nativejar or anything like that, just the qtjambi-win32-msvc2005-4.4.0_01.jar in the classpath and that is enough to load it, jpeg and svg plugins and all. The good thing is that the files included in the webstart are produced directly by the ant script with all dependencies etc set up properly… (well… almost properly, it took us an evening last week to get it really working, but now it works properly). Because of the fixes to memory management and deployment Eskil and I got these offical diplomas:

So, what more is there to say… Try the webstart with its new demos, download the packages and start hacking!

-
The Qt Jambi Team

Well, just in time for WWDC, we have decided to put another alpha release of Cocoa out today. Even though we have had snapshots available for a while and we still are a long way from being complete, we thought it might be nice to let others give it a shot. In addition we also are providing a 64-bit binary version, we would have had 32-bit in as well, but ran into an issue when building, so there is only 64-bit available. These will replace any other Qt binary package, so handle with care.

Here’s what I can remember that has changed since the last alpha:

• QWidget::setMask() works
• Drag and drop now works
• support for sheets and drawers
• A new way of working with dialogs (QDialog::open()) that makes it easier to make
  window-modal dialogs (sheets) on all platforms, specialized versions available for
  QFileDialog, QColorDialog, and QFontDialog.
• Contains changes that are part of Qt 4.4.0.
• QTKit backend for Phonon (partial support).
• Tablet support
• Preliminary support for unified toolbars.
• The package should build in run and both 32- and 64-bit.
• Fixes for mouse event handling and popups
• Fixes for positioning windows on screen

What’s not working and we are aware of them (some of these are still from the last alpha, but weren’t mentioned then, but they are still broken). Most we plan on fixing (or in the case of NSApplication, minimizing chances of that happening).

• Widgets that use QFocusFrame for displaying the focus halo will not be “clickable,” but you can still interact with them with the keyboard. This includes widgets like QLineEdit, QTreeView, QSpinBox, etc. If you need to test things, you can temporarily set the Qt::WA_MacShowFocusRect attribute
• Networking
• Accessibility
• Input Methods
• Most keyboard shortcuts do not work
• Designer will not run with all its plugins, even with plugins removed, it will not work properly. Please use a released version of Designer to edit your forms.
• Widgets that contain a QFontComboBox will currently take a long time to show the first time.
• We are using a NSApplication subclass for tablet events and a NSApplication delegate for handling some events. If combining this with an application that already has an NSApplication subclass, you will not get all tablet proximity events, if you are using an NSApplication delegate, Qt will not be able to use its delegate and some events like window activates may not be delivered as QEvents.

So, in between all the other Mac-related buzz, don’t be (too) afraid to give this alpha a download and see how it goes.