sushi (again)

Still in the same Sushi Factory. As usual, the fried prawn rolls quickly become my all-time favorites.

Mela Festival, Oslo

There is Mela Festival this weekend in Oslo. Lots of food, dance, music, fashion, stalls, as well as some interesting children activities. Too good to miss!

(see some more pictures)

Qt 4.4 and Maemo

After playing a while with Qt 4.4 on my N800 (will be the same for N810), the impression of "slow" (like latest Adam's latest post) is something that I predicted will soon come out. So far, my very brief investigation reveals that the cause for this is both simple and sad: the Maemo's X is running 16-bit visual (N8xx's display is Highcolor only, not Truecolor). Thus, if you do something fancy with 32-bit stuff, like running a QPainter on a Format_ARGB32 or Format_ARGB32_Premultiplied QImage, then basically you force a 32-to-16 conversion every time you blit the image.

Take a look at PictureFlow, the infamous clone of Cover Flow. You can just checkout it, run qmake and make as usual and start to have some fun (all inside Scratchbox, and after that transfer it to the N8xx).

Surprisingly, it runs horribly slow, probably less than 5 fps. Consider than PictureFlow does its magic by straight pixel manipulation and then just blit the result, this looks really weird. However, it was found out that Qt needs to perform the conversion from 32-bit image to 16-bit pixmap for every single frame, hence the terrible slow down. In short, there is more CPU power wasted for the blitting vs for the rendering. Check your callgrind output to confirm this.

Good news: this is something that can be fixed (both in the application level and probably inside Qt). Personally this one is my favorite aim for Qt 4.5. Once we start to see ported Qt apps for Maemo, we can't afford to allow a potential performance penalty like this, it would just give a wrong impression of Qt. Don't you agree?

Sidenote: 16-bit can be useful because (on a non-accelerated graphics system), you can perform faster full-screen update (less transferred bytes). 32-bit is however easier to handle because each color component lives in a separate byte.

Yes, honey (or the beauty of double meaning)

A sunny morning in a small coffee shop.

"Hi!"
"Hi!"
"I'd like one chai latte, please".
"OK."

The girl went on to prepare the order. After a while,

"Do you want honey or sugar?"
"Yes."
"Yes what?"
"Yes, honey."

One second passed. Then we shared a laugh.

(Just like in a [HB]ollywood movie)

dirgahayu

August 17th is Indonesia's independence day. Merdeka!

svg-to-png using (Qt)WebKit

Related to the recent discussion on some problems of Qt SVG renderer when drawing the Oxygen icons, I decided to sit down and wrote an example of yet-another SVG renderer by using QtWebKit (available since Qt 4.4.0). Check out the code if you're interested, it is part of the Graphics Dojo examples.

The major difference between this WebKit-based tool compared to QSvgRenderer is that it should handle SVG features which are supported by WebKit. Note that QtSvg limits itself only to SVG Tiny 1.2 without DOM API and scripting (due to various reasons). On the other hand, SVG support in WebKit will be improved over the time. Yes, fancy stuff like filter effects are not fully implemented yet (at least, in QtWebKit), but we are working towards that.

For those who can't wait for the DOM API in QtWebKit, you can see the example of poor man's way of doing it, i.e. by (ab)using evaluateJavaScript() of a web frame. Here it is used to get the SVG width and height attributes. As a hint, if you are unsure about the DOM tree, its elements and/or their attributes, then open the SVG in e.g. Arora or the Demo Browser and use the Web Inspector to check it. The JS console is also helpful to try out various thing right when you view the SVG.

Obligatory screenshot follows:

And while you are there, check out also other fresh dojo examples: zooming text and old-school radial blur.

quattro quattro uno

In case you live under the rock and miss Thiago's latest blog post, Qt 4.4.1 was just released. This is just a few days after KDE 4.1 was announced and close to three months after Qt 4.4.0 was out.

This patch release adds tons of bug fixes to the 4.4.0 release. For the WebKit team inside Trolltech Nokia's Qt Software Unit (by team here it means a group of developers you can count with one of your hand, and still not everyone works full-time on WebKit), beside the usual feature development (like Phonon-based media and Netscape plugin support), we did spend a lot of time fixing important bugs, as evidenced from the 4.4.1 changes.

On to Qt 4.4.2 and KDE 4.2. The latter would be ten percent of the ultimate answer to life, the universe, and everything...

seas would rise when I gave the words

In the context of improving the user experience (read: wasting more CPU cycles), I couldn't resist to add a bunch of random and experimental improvements to the experimental feature of live preview in Arora.

First of all, I gave up the idea of having a top-level widget, like a QToolTip's label, to display the preview and this would already wipe half of the annoyances that might show up. Bonus, this makes it easy to have a non-rectangular, translucent tab preview without the need to rely on composite support. Look at the shot below:

The callout shape, along with its subtle shadow, is very easy to do with QPolygon. Readers with sharp eyes might notice that the preview is not opaque, you can set the opacity as you like. In addition to that, a simple #define will make the tab preview to use OpenGL for scaling. This is obviously faster on graphics cards with proper, non-buggy accelerated drivers.

So far everything is done with only around 250 lines of code. I suggest you to give it a try (check out the live-preview branch). Be careful, as this live preview feature is very addictive! Opera and Firefox-with-Tab-Scope-extension users know for sure what I mean.

Another thing that I'm still undecided is a simple and subtle animation. With QTimeLine, again it would be quite easy. I have another 20-second screencast (watch on YouTube or blip.tv or get the 1.4 MB Ogg Theora video) that demonstrates this:

Maybe this should be disabled by default. Here I would also like to mention that right now there is no plan from my side to push this to upstream. In plain English: you won't see this feature in any official release of Arora in the near future. When, at a certain point in the future, I feel confident enough with this feature, then thing might change. But right now, if you want to try it, just pull my branch and compile it.

And yeah, I watched The Dark Knight the other day and it's simply magnificent!