Gluon sprint + QtDevDays

So last few days i've been in munich for the Gluon sprint and the Qt Developer Days.

Before starting my summary i want to thank the KDE e.V. and Qt/Nokia for paying the trip to Munich, the accommodation, letting us use the Qt/Nokia offices in Munich, giving us free entrance to the DevDays and also free opportunity to do the Qt Certified Developer Exam (easy if you are a seasoned KDE dev i'd say (hope i pass it :D)).

That said, lets start :D

Gluon sprint started friday at 10pm for me when i got to our hostel, there i met with Sacha and Sandro, had some drinks and went to sleep waiting for the next day.

On Saturday, HarriF from Qt/Nokia picked us up in our hostel and guided us to the nice offices Qt/Nokia has in Munich, there we started some presentations about gaming creation IDEs so all the participants of the sprint could see the idea of what Leinir wants for Gluon Creator. Mid-afternoon, Knuth joined us and cared for us for the rest of the day, even getting us some food for dinner when the waitress was hesitant because it was already late.

On Sunday we started to do some work involving designing, refining of classes, creating d-pointers for classes, improvements on some classes to make it more easy to be cross paltform, etc. HarryF joined us for a while and he got himself parts of the sample gluon game (Blok) working on the Mac, cool stuff.

Monday continued with work on Gluon stuff with fregl, karli and SaroEngels joined us due to the proximity of the DevDays. The very monday afternoon we headed to the Hilton where the welcome reception sponsored by Tieto. A company that was the Platinum sponsor of the event, that said to have lots of Qt experience but whom i had never heard of. They were actively showing plasma on the S60 emulator, no idea if they have anything to do with the plasma port to that platform, if they have not it's a weird thing to show.

Tuesday was DevDays talks start, it all began with Nokia VP for Qt speaking of the Qt Everywhere idea (we had a Qt-based coffee machine :D) which includes everything you can think of except the iPhone and Android (some conflict with Nokia interests?). The starting video showed Marble and KDE screenshots, nice touch :-) Lars spoke about the next generation of Qt followed by Walter Bender talking about Sugar, that uses pygtk and when he asked if Python Qt would be supported he got a no, there's some company called riverbank that does it but Qt/Nokia does not do it. I wonder what happened to PySide that not even Nokia employees talk about it... Then ¿our own? Matthias Ettrich came out to the stage with a laptop with a huge KDE sticker running Ubuntu and spoke about the Declarative interfaces thing, cool stuff, but mostly for the smartphones i'd say, also it is bad that it won't respect native style of "widgets".

After lunch talks continued without anything worth mentioning except the shameless plugs for QtCreator in each of the talks (guys we know it's not a bad tool, no need to say "look what it does, it's cool") and the unprofessional way of referring to the iPhone as "the phone from the fruit company" and Android as "the robot from the ad company". Grow up.

Then we headed for the 15th floor for some drinks while the rooms where prepared for dinner where the Fact or Crap Quizz Contest was held, my table (the gluon team table) was just 1 correct answer away to qualify to the final, so close to those shiny phones....

Next day i attended some more talks about features that seem specifically developed for smartphones (gestures/animations/stateMachine) and also two KDAB given talks, one about Multithreading by Mirko (with some Steven Seagal resemblance) and Qt Kwan-Do by Mirko and Till.

All in all a very nice experience, more suit-y than Akademis but still nice to see that much people attending a Qt meeting, being the largest Nokia developer oriented event this year.

And last but not least, Sandro is luckiest man in earth, he won two consecutive raffles, take that statistics :D

Qt for S60 not as cool as real Qt

Ok, Qt for S60 *is* real Qt since it was merged in mainline Qt not too much ago, but it still has lots of things that make it not the very good toolkit we are used too. For example Qt 4.6 in S60 will have a QFile that won't support unicode names in files. :-(

Is the X11 engine slower than raster just because of the drivers?

Here was i profiling KSquares and discovered that when painting an antialiased dashed line using the Qt X11 engine you hit a code path in which Qt tries to detect for each dash of the line which other dashes intersect with it, that's right a O(n^2) calculation that makes no sense, that since you are drawing a line the intersections it will find it's that a dash only intersects with itself. So seeing things like that i wonder if the Raster engine is faster because X11 drivers suck we have been told or it's that the X11 engine code is not as good as it could be. I've checked and the raster engine has no such "bad" loop

How to make foreach loops that don't suck

Calling values in Hashes/Maps/Sets

QHash<QString,Plasma::Meter*> meters;
foreach (Plasma::Meter *w, meters.values()) {
  w->setLabelColor(0, theme->color(Plasma::Theme::TextColor));
}


This code is iterating over the values of a hash and doing something over them. Everything seems ok, but it's not, it's calling values() on the hash and that's causing the creation of a temporary list with all the values of the list, effectively causing a bigger memory usage and iterating over the list twice (one to get the values and other to do something over them).

You can write something that does the same without these two problems doing

QHash<QString,Plasma::Meter*> meters;
foreach (Plasma::Meter *w, meters) {
  w->setLabelColor(0, theme->color(Plasma::Theme::TextColor));
}


So if you are using values() in a foreach, just remove it and your code will be instantaneously faster.

Calling keys in Hashes/Maps


QHash<QString,Plasma::SignalPlotter*> plotters;
foreach (const QString& key, plotters.keys()) {
  plotters.value(key)->setShowLabels(detail == SM::Applet::High);
  plotters.value(key)->setShowHorizontalLines(detail == SM::Applet::High);
}


This is calling keys() over the hash, this, as values(), means going across the container and creating a temporary list containing all the keys of the hash, that's a waste of memory when you could simply use a proper
QHash<QString,Plasma::SignalPlotter*>::const_iterator
and just iterate keys one by one.

Then it does plotters.value(key) twice, ok, accessing a value in a hash is amortized O(1) but still you are going to calculate the qHash of the string twice for no reason.

But more important, what the code is doing is actually iterate over the values, so the proper way is doing

QHash<QString,Plasma::SignalPlotter*> plotters;
foreach (Plasma::SignalPlotter *plotter, plotters) {
  plotter->setShowLabels(detail == SM::Applet::High);
  plotter->setShowHorizontalLines(detail == SM::Applet::High);
}


Probably in this case the net benefit is not much because probably the number of element of plotters is small, but there's no need to write inefficient code when the efficient one is as easy to write.

And of course it could be worse. If plotters was a map instead of a hash, lookup would be O(log(n)).

So if you are using keys() in a foreach, please think twice what you are doing and if you only need the value, iterate of the container and if you really need the key use a proper iterator to avoid constructing the temporary list.

QImage::Format_ARGB32_Premultiplied is your friend

If you have looked at QImage in Qt4 you'll have noticed that there is the typical QImage::Format_RGB32 and QImage::Format_ARGB32 plus QImage::Format_ARGB32_Premultiplied.

Maybe you have wondered why is there, well, i'll tell you, it's FAST.

I have done a simple test rendering 100 times gear-flowers.svg wallpaper in a qimage of 1024x768. The results follow

RGB32: 20351 msec
ARGB32: 39273 msec
ARGB32_Premultiplied: 20248 msec

So if you look at the numbers, you'll see ARGB32_Premultiplied is actually faster than RGB32 that is not even producing correct results.

So QImage::Format_ARGB32_Premultiplied should be probably renamed to QImage::Format_ARGB32_UseMeBecauseImFast :D