My blog has been moved to

Sunday, September 27, 2009

Maemo Summit 2009, Amsterdam, 9-11 Oct

Maemo Summit 2009

Another exciting event coming up soon: Maemo Summit 2009! This time it will be in Amsterdam. My flight ticket is secured already, I look forward to it. And of course, since this will be also my first visit to Amsterdam.

My talk will be on Friday afternoon, see the schedule for details. Although the title "Cross-platform with Qt" is a bit boring, rest assured you will see showcases of many things (which I can pack in 25 minutes) Qt is capable of doing.

A few other Trolls will be there as well so go there and find us. In all cases, if you are around and want to have a chat, drop me an email (ariya.hidayat AT gmail DOT com).

a moment, a love, a dream, a laugh, a kiss, a cry

pizza (again)

Seems autumn always calls for my service, hence the usual pizza-baking obligation, as evidenced from the photo. Recipe? Check what I have posted last year. A slight variation: slices of pineapples :)

Wednesday, September 23, 2009

frozen in the headlights (have I made the final sacrifice?)

This slick stuff is mostly educational (for the lazy, see the 30-second YouTube video courtesy of Alessandro). With all the accelerated graphics (with those alphabet soups) these days, who on earth uses ray casting for real-world apps? Nevertheless, since I still keep the piece of code (read: a function, literally) I wrote ages ago, why not giving it a try again?

Testing it on Nokia E71 (powered by ARM 369 MHz processor), I am content to get a consistent 25 fps at QVGA resolution (and the code is still portable!). I reckon I need to resort to platform-specific, e.g. Anti Tearing API for S60, if I want to push the frame rate further.

For the code and the explanation, head to the S60 ray casting demo. You would need the Qt 4.5 Tower release to build it for your favorite phone. Also, you need a four-way controller as I haven't bothered to let it run on a touch device.

Final (friendly) reminder: use sloccount and check yourself how long this example is. Why? Because usually people think I try to trick them when I reveal the size of the source code :)

Friday, September 11, 2009

SVG: parsing and content optimization

A few weeks ago, just for a change (between the usual QtWebKit bug-fixing and patches juggling), I did take a look at our QtSvg module. According to some internal reports, QtSvg is not fast enough when parsing a large and complicated SVG. Of course, slow is relative, slow to what. And arguably, parsing time is not as important as rendering time. But if you stash your user-interface elements in some sort of SVG theme, loading time becomes a factor (caching the pixmaps whenever possible also helps). Of course, reduced size served in a web server can decrease the bandwidth as well (think of all the SVGs in Wikipedia).

Still, I decided to have a look, just in case there are low-hanging fruits I can grab. And I was right, far from being an SVG expert, with just two days of work I managed to squeeze its performance a bit, which you'd enjoy already in the recent 4.6 preview.

The chart above - shorter is better - represents the comparison of the time spent in QSvgRenderer::load(), measured using CPU tick counter (in millions of ticks), comparing Qt 4.5 and 4.6. I also tested some other files as well, see the bigger bar charts. In all measurements, the 95% confidence intervals were well below 1%. In-house Theme refers to an internal SVG that unfortunately I can't share. Tiger is the SVG version of the famous head in PostScript (taken from GNU GhostScript), something I have shown before. Imperial Coat of Arms of France is another complex SVG, from Wikipedia Commons. World Map is the public domain blank grayscale world map from Wikipedia. There are a bunch of other test files I used, they mostly show the same improvements.

As you can see, Qt 4.6 would enjoy a bit of speed-up (in some cases up to 1.4x) when loading and parsing SVG.

However, I did not stop there. For the fun of it, I quickly hacked a Qt-based, command line SVG minifier, dubbed SVGMin. More about it can be read in the detailed Quick Start, but basically it tries to eliminate redundant garbages which have no effect whatsoever in the final rendering.

What follows is the chart showing the same type of measurement but I added the result with the minified SVG (see also the full comparison chart). The result should speak for itself:

I plan some more improvements to the SVG minifier, for example collapsing a single grouped element (<g><path ...></g> makes no sense), group a bunch of nodes with similar attributes (no need to duplicate the same fill colors over 100 circles), remove useless attributes (why there is fill-* for fill:none?), and many others. Hold your breath.

Tuesday, September 08, 2009

the game of escalation


Often I ask myself how long I would still want to stay in the software industry. Before I started my professional programming career, I never thought that this wonderful world of software craftsmanship is full of complaints, frustration, anger, and hostility. Perhaps that is just the reflection of people wanting to achieve the best things they can do. When you aim for a perfection, anything good enough will not be satisfactory.

I can't say for sure, but somehow I feel that I am still heavily influenced by the positive gratitude mentality, even in the case of calamity. When you have an accident and your right arm is amputated, someone reminds you, "You are lucky, you could have lost your legs!". Losing an arm is considered lucky? This does not mean that we bury our head in the sand and forget the fact that one arm is gone already, it just means that we should not be blind to the fact that things could have been worse. By doing so hopefully we keep things in perspective and move forwards as positive and as best as we can.

One of the lessons I learned so far is the amount of extrapolated verdicts you would get from the users, the developers, and/or the customers. Any bugs, any annoyances, no matter how small it is, are sometimes blown out of proportion. I call this the Universal Rule of Blaming. A customer complains, the company desperately grabs a consultant to help, he finds the bug in the toolkit, the toolkit guy chains it further to the operating systems, and so on. Of course, for each stage, the amount of anger and loudness of the screams increase exponentially. Basically, nobody wants to be the escape goat.

Sadly, everyone in the business of doing software seems to forget that making a software is just like another engineering project. It has its constraints, the resources are limited, the time is the (common) enemy, priorities must be set, and practically it is impossible to achieve 100% perfectness. It is the classic optimization problems. Thus, the responsible people have to make some decisions and these decisions can't please everyone. There will be people alienated with such decisions. Anyone ever done any kind of sensible business knows exactly what it does mean. Every customer feels that he is important (I mean, who does not?), yet a typical company has a lot of customers and such a company is always ready to disappoints 10% of the customers, rather than 90%. As you can guess, it is a matter of minimizing the loss. When a business guy asks his customers, "Hey, I need your feedback" and he really means it, he is not trying to be nice, he is trying to save his business.

However, my concern is not on the technical matters, but rather the non-technical side. When you are angry, you may say some words that you may regret later. Unfortunately, getting mad because of software annoyances can trap you in the same, if not worse, situation. What I often witness is that people start guessing, accusing, throwing blames, up to the a point where it becomes counter-productive and getting personal. You all know what happens when a developer takes it personally: a cycle of violence is about to roll. Once a while I try to stand in the line of fire (a big mistake, I know) in order to bridge both parties. No luck, it is like being trapped in a DMZ and people will just release their steam and waste their bullets to me as if they are happy to find a new bandito to kill. Ever wonder why some developers take the holy vow of silence?

The most common case is the why-my-bug-is-not-fixed drama. For example if I do not fix the problem X on the platform Y, people might start rambling on anything from "you secretly plan to drop support for Y" to "you rather focus only on feature Z instead of fixing X". There are various reasons I still do not manage to provide you the fix, but because of the frustration, people tend to invent and believe in some kind of conspiracy theory. Feel free to write a long Pulitzer-quality editorial on why the lack of the fix destroys your million dollar business, but no need to cross the line and start imagining things.

The drama can continue in a developer conference, where a guy might ask a simple, seemingly innocent question (even in a keynote speech) such as "Why don't you fix (my) bug 123? Why do you work on feature 456 instead?". Believe me, I saw that happened many many time. Those questions will put both the speaker and the audience in a awkward situation. While I fully agree that every bugs must be fixed, throwing such a question which only has the intention of embarrassing the developer in front of everyone is way too dirty for my taste (not to mention that, like often the case, our poor little developer never took any How to Deal with Angry Customers course). In fact, every time I encounter this kind of scene, I make a mental note to stay away from that guy. And I am sure I am not the only one who is doing that. Like I often expressed, we are not in the kindergarten anymore, screaming does not make the solution comes faster. Time to make a ThinkGeek T-shirt for that?

Thus, I reached a conclusion that there are two types of software guys: those who symphatize with the difficulties and problems of delivering a perfect product (because they are trying to do the same, "Welcome to the club!") and those who just like to shift the blames to others (because they get customers banging their doors). Nobody likes to deal with angry customers so the choice is (not) hard: either you take the blame (after all, you are the one who is doing the direct business to your customers) or you pass it along (every one of us is a customer of someone else's product). In the latter case, you just become yet another angry customer.

Noblesse oblige.

Tuesday, September 01, 2009

wanna curve away? it's such a perfect day

If you were at my Special F/X talk, Desktop Summit in Las Palmas, or if you watched the recorded video (135 MB Ogg), you might notice the tongue-in-cheek gratitudes to Lufthansa dan SpanAir I expressed at the beginning of the talk. The story goes as follows. As all of us, the Trolls, left Oslo to fly to Las Palmas, our flight got delayed twice, in Oslo (by Lufthansa) and Madrid (by SpanAir). Like every other dedicated (read: foolish) hackers, I took advantage of the delay to fulfill my dream (read: obsession): writing my own presentation tool. Hence, the special thanks.


Of course, like every other dedicated hackers, I cheated (after all, great artists steal). Inspired from the previous discussion with Simon (and Holger), I just took S5 and wrapped it with QtWebKit. The result is something I called s5runner. The 200-lines Qt/C++ code (and PyQt, thanks to David) is best demonstrated by watching the following short screencast:

Few extra features added on top S5 are screen blanking (white or black), night mode (just for the fun of it), syntax highlighting (useful for code snippet), countdown timer (because my laptop has 100x computing power vs my wristwatch), and (my favorite) live editing.

I will definitely reuse this for my upcoming talks.