I uploaded another wonderful Qt example to http://ktown.kde.org/~zrusin/examples. This example has been written by Trond Kjernaasen (one of the Samurai Graphics Assassins, hobbies include death metal and beating Trolltech’s QA department at ping-pong). The example shows a wonderful mixing of OpenGL with Qt native rendering. You can type in any phrase, the application will try to look up the images on flicker and then display them in a very eye-candish kind of a way. The application looks like this (but remember it’s all nicely animated so you want to see it on your machine).
Trond uses pbuffers to make it all work together so make sure your card supports them. Direct link to the code is here. (some people reported crashes when running on latest NVIDIA driver so watch out )

Today, we released the third and final tech preview of Qt Jambi. At the same time, Trolltech announced a contest for Qt Jambi developers, so if you’re interested in getting some loot, go download the new package, make something awesome and send it to us.

About the release, though, I’m especially excited about this one, primarily because it’s based on Qt 4.2, and thus gets to benefit from all the nifty new features in Qt. On Windows and Linux, you can still use Java Webstart to run the demo launcher without manually unpacking and installing anything. The link is on the download page, and here’s a quick run-down of what to look out for:

QGraphicsView
One of the highlights of Qt Jambi TP3 is the 2D canvas QGraphicsView. It’s an extremely useful, item-based canvas API capable of handling millions of items efficiently. The items can be vector graphics, text, pixmaps, et cetera, collision detection is built-in, it’s based on a model/view architecture, and everything about it is in general very pleasing. Here’s a bunch of colliding mice:

com.trolltech.qt.svg
Although SVG support was introduced to Qt in version 4.1, it has not been included in previous Qt Jambi releases. We’ve added this package as well in TP3, and there’s even a hot new example of how well it plays together with graphics view.

Javadocs
One common request from our users so far, has been to add javadocs to the Qt Jambi packages. This has been our plan all along, and in this latest release, we finally have documentation for the Qt Jambi API in javadoc format. This means that, if you are using Eclipse for your Qt Jambi development, you can get easy access to documentation in the code completion list as you write your code. All you need to do is edit the build path entry for your qtjambi.jar file in the properties of your project, and add the location of the javadoc there. Here’s a screenshot to make it easier:

What else?
There’s actually so much new stuff in TP3 that giving everything a separate paragraph would make the blog infinitely long (approx.) Some of the stuff you might want to read more about though, is

There’s a lot more as well. You could read the Qt 4.2 intro to see some of it. Hope you have fun trying out all the new stuff and don’t forget to enter the contest.

The responses to my latest blog have been hugely disappointing. I thought about ignoring them but since they might be representative to more than just one individual I decided to address them in a whole new blog entry. In no particular order:

Q: Results show that Cairo is bad and slow, is that true?
A: Of course not. That was never what I wanted to show or ever implied. It’s so disappointing to see people being so negative and then putting me in the middle of it all. Let me explain using a simple analogy: when two great soccer teams are playing, lets say Brazil and Italy and Brazil wins 3:0, it doesn’t mean that Italy is horrible. It means that Brazil was really good at that particular day, a lot better than Italy. Surely before the next game Italy will be better prepared. Graphics is difficult. Trust me I do it every day. One graphics framework being better at something doesn’t imply anything negative about the other. All it says is that the framework that was better at something, is really good at that something. Qt is really good at rendering polygons. _Really_ good.

Q: Those tests don’t mean anything for most use cases which is rendering images and rectangles!
A: Right… Of course frameworks that focus on those are not vector graphics frameworks. Writing a vector graphics framework that is not good at rendering polygons is a little silly. One might as well stick to pure raster graphics with images/rectangles and it’s going to be a lot easier. I’d love to see KDE move towards dynamic, resolution independent interfaces. For the things we’re planning, polygon rendering is representative of exactly what we’re doing.

Q: Cairo will catchup and it will be better! It’s actively developed.
A: That’s great. Of course, it’s not like the whole graphics team at Trolltech is being fired because Qt is so good there’s nothing to be done anymore. We work on graphics every single day so you have to expect Qt to be getting rapidly better.

Q: You will not repeat the benchmarks when Cairo or something else is faster!
A: Right, because that would imply that I have to update and compile every other framework our there every single day and repeat the tests every single day. There’s no way I could physically do that (or even be willing to waste my time like that every day). It’s up to the framework developers. If you work on a framework, test it after you make some changes and let me know when something changes. If anything will come even close to Qt I’d love to see it. I’d love to stop having to compare Qt to Qt when I do tests. It’d be great if someone would make my life a little bit more challenging.

Q: Tests have to be unfair!
A: What are you basing this on? You either trust me as an Open Source developer or you don’t. And if you don’t then don’t waste mine and yours time by reading my blog. The code for Cairo benchmark is at http://ktown.kde.org/~zrusin/examples/cairorender.tar.bz2 if you think it’s unfair, feel free to send me fixes (and don’t be silly by trying to render polygons to a cached surface and then repeatedly composing the surface, like I said the tests measure polygon rendering, not image blitting).

Q: Ha! Qt is not Open Source, Cairo is the standard!
A: Not even mentioning that both of those are wrong, how does that relate at all? I am first and foremost an Open Source developer. Yes, I do prefer to write desktop code in C++ than C which was the basis for me joining KDE in the first place, but that’s all. If I’ll decide to quit Trolltech at some point and will get an offer from company supporting GNOME, I’ll start contributing to GNOME the next day. It’s all Free Software, that’s what’s really important to me. Qt is Free Software, that’s why I work on it. I’m an Open Source developer, I just happen to work on KDE. I moved half way across the globe, to a country where I knew I’m going to be hungry all the time, just to be able to work on Free Software full time so please skip my blog if you want to bring something as ignorant as that here.

Q: Give me the code?
A: Why? I gave you the dataset and I told you what to test. If you question my results, go write an application rendering polygons and see for yourself. It’s an absolutely trivial operation. If you can’t do that then what’s the point of you fetching my code? The bottom line is that if you don’t believe me already, you won’t either way and the whole discussion is moot. The people who cared knew where the code was and if you’ll look at the date you’ll notice the code was there from before I posted the blog (the link to the code is two paragraphs above).

Q: The test is not representative of anything!
A: Of course it is. What would be the point of me writing a test not representative to anything? Like I said in the second paragraph the test is completely representative to the things we want to do in Plasma. If your application renders SVG’s, Flash, fonts as paths, complex shapes or actual vector shapes, the test is fully representative of the results you’ll see. But again, it doesn’t imply anything negative - so it’s not that Cairo will be very slow in those cases, it’s that Qt will simply rock them.

Q: But what if something else would be faster than Qt? Would you post results then?
A: Well, I don’t exhibit self-destructive behaviour so no, of course not. I’d fix my code to make sure it’s faster and then I’d post them. This is how this works. If there’s anything, and I do mean anything that Qt is slower at than any other vector graphics framework, be it Microsoft’s WPF, Java2D or Cairo we’ll fix Qt and make sure it’s either faster or at least at the same level. Like I said, I’d love to be able to test Qt against something else, rather than Qt itself. If you can provide me a benchmark that shows Qt slower at anything in comparison to any other vector graphics framework, I’ll make sure that it’s not the case for long.

A lot of people has been asking me about some performance comparison for the vector graphics framework we have. Rendering polygons, especially when we’re dealing with stroke, tends to be the most expensive rendering operation performed in vector graphics. I constructed a little test, which tests raw polygon rendering power of Qt and Cairo.

For the test I used the latest Qt main branch, and the master branch from Cairo’s Git repository.

The test is composed of rendering three complex polygons. The first one is a text path, the second is a small polygon with a large amount of vertices that fall on the same scanline and the third one is a huge polygon with about 100000 vertices.

The results measure frames per seconds at which each framework was capable of rendering the given testcase. Therefore the larger the better.

I tried being as objective as possible. All tests go through the whole pipeline, meaning I tried to make sure that the framework doesn’t cache too much and actually renders what’s being asked. I used latest version control code for all frameworks. The data used in the tests is available here: http://ktown.kde.org/~zrusin/complex.data (newline separated polygons whose coordinates are comma separated). All tests were written to utilize antialiasing.

Oh and all tests have been done on a machine with Pentium(R) 4, 3.20GHz processor, 1 GB RAM and NVIDIA 6600 with 1.0-9625 drivers.

Having said that the results were (charts follow):
First just pure Cairo vs Qt native performance:

Qt was respectively 7, 5 and 6 times faster. Than Cairo in those plain tests. This is a direct result of Qt’s new wicked tessellator in 4.3.

But all the frameworks have many backends, the most interesting one being the OpenGL backend. For 4.3 I devised a new method of rendering polygons for the OpenGL, based on stencil clipping. So lets see how Qt’s OpenGL engine compares to Qt’s native XRender engine:

The difference is huge. Qt OpenGL rendered the first polygon at 487 frames per second vs 76 in Qt XRender engine. Note though, that in XRender we tessellate which is of NlogN complexity, in OpenGL I’m able to render polygons in a completely linear fashion. The method does deteriorate for polygons with 80000+ vertices due to large amount of triangles that has to be processed - it’s a GPU bottleneck though which means that with a more powerful graphics card those results would skyrocket.

Finally, lets combine the results of all the frameworks and see how they match-up:

The reason for Cairo with Glitz backend yielding the same results as Cairo with XRender backend is that polygon rendering in both of those goes through the same client-side steps all the way until the final blit and it’s not the blit but the tessellation and rasterization that are the bottlenecks. I added Amanith to the results because some people mentioned it in my blog before. Both Amanith and Cairo (Cairo only with native XRender backend) crash on the last polygon. In Amanith the tessellator seems to fall apart. In the Cairo case application crashes in the XRender code, so most likely rasterization code is not keen on one the trapezoids that Cairo sends it. Cairo with Glitz backend render the last polygon at about 0.2 frames per second (but doesn’t crash which again shows that it’s likely XRender’s trapezoid rasterization code, especially that Carl couldn’t reproduce the given crash on his laptop). Interesting fact right now is that Qt with XRender is way faster at rendering polygons than Amanith and Cairo with Glitz, both of which are OpenGL accelerated.

Notes: I know Carl is working on a new tessellator for Cairo which should exhibit the same logarithmic behaviour as the current Qt one. Carl was kind enough to even send me a tarball of the branch in which he’s working on it. Unfortunately, although the results for the first polygon were at about 13 FPS (2 frames per second better than the current Cairo tessellator) they were degenerating for other two polygons. This is most likely due to large precision of the new tessellator (in both #2 and #3 testcases you get vertices close enough to consider them coinciding without any visual artifacts). Once Carl will get the precision down and integrate the new tessellator I’m going to run the tests again.

Conclusion from all those tests is that right now Qt is leaps ahead of any other vector graphics framework in terms of raw performance. Nothing comes even close. Qt’s OpenGL engine is so fast it’s basically unfair to compare anything else to it.

Objectivity aside, Qt rocks. It really does. And if you’re using Qt and not using Qt’s rendering architecture, everyone should point at you and make fun of you for not having complete and utter trust in me, as the only true graphics ninja and the team of Trolltech’s Samurai Graphics Assassins.

hmmm..

re: Joys of Freedom, R.I.P Opie
http://zecke.blogspot.com/2006/10/joys-of-freedom-rip-opie.html

Life is like the tides and the ocean.. sometimes rushing in, and other times rushing out. Sometimes it is rough and windy, and sometimes it is smooth as glass.

Opie is not dead. Slightly dormant, but headed for resurrection.

Qtopia is free software, you can still download it for free off of trolltech.com. It’s true, Trolltech has not yet released Qtopia 4 as GPL. Qtopia 2 is still very viable and useable software. Just because something is old, doesn’t make it unuseable. Some developers should actually try using software sometime, instead of being so intent on always needing the latest and greatest. I would love to own a ‘69 Shelby. I am not even afraid when someone says it might be ‘obsolete’.

guyhlem’s statement about Opie dying “I’m asking everyone to stop working on Opie and join the Qtopia bandwagon.” this was because Opie was duplicating effort (a.k.a. fluff). Also, Opie is not compatible with Qtopia. I know, I have ‘ported’ a few applications between the two, and an app made for Opie will not compile/run with Qtopia, without, of course, libopie and friends. A lot of Qtopia apps wont run on Opie unaltered either. hmmm compatible. What’s that about the ‘Description’ and ‘Notes’ fields that cause trouble between the two?

Yes, it has been a long time since Trolltech released a new GPL version of Qtopia. But blaming Qtopia releases for Opie’s lack of development is just not right. There are quite a few open source projects living on their own. What he didn’t mention is those patches that _were_ included, the communication that did happen (including hiring of an Opie Core developer [me!]), and those devices that were released because of Qtopia and Trolltech.

Now there is the Greenphone, due out shortly, and yes, Trolltech will abide by the licensing of the software, of course. There is also the task tracker at trolltech.com, so you can report bugs/ fixes and feature requests to your hearts content. There is also an SDK that includes KDE! I have also heard some statements from some developers about what the Greenphone has/doesn’t have/supposed to have/better off having, coming from people that could not know, as it hasn’t even been released yet.

As well as an upcoming Qtopia 4.2 release, which will spur on Opie II! and since I have been deemed Opie’s last developer (and yes I am also a Trolltech employee, so there is no lack of communication between the two groups/community) I guess it’s up to me to rename it. How about Qtopie!

Its been a long time since gutenbrowser has been developed. For those that do not know, its software that searchs, downlaods etexts from the aprox. 19,000 free books from the Project Gutenberg.

This time, I can develop the embedded and desktop version in the same tree, finally!

It’s not much to look at, but using a database really sped up the title and author searches.
That, and because Qt 4 really rocks, this thing is fast!

hmm.. perhaps I should rename it Qutenbrowser!

Here’s a screenie for the desktop version.

I’ve been getting a lot of questions about writing semi transparent applications with Qt. So I’ve put up an example showing once again how to use ARGB visuals with Qt. The example, just like the old one I showed a while ago looks like this:

The code is available at http://ktown.kde.org/~zrusin/examples/argb.tar.bz2.

By the way of this example I would like to ask some KDE people to stop abusing the fact that I work for Trolltech. What has been happening a lot lately is that people send me emails asking and in some cases actually telling me to do X or Y for their application or send them code to show them how to do Z, which would not be a problem if not the fact that if I won’t respond within a few hours they email qt-bugs referencing me by name and writing that this is a “bug” for me. That’s ridicules, please don’t do that. My motivation to help you is not proportional to the amount of emails you manage to get in my inbox. And if I tell you on IRC that I can’t reproduce a bug and I’ll need more informations, for example what version of X.Org and on what drivers you’re running it, then sending the same bug you told me about on IRC to qt-bugs will not magically make me fix it, I’ll still need the same extra informations to get anywhere. So please have mercy on me and be reasonable I am physically not capable of addressing everyones graphics related issues and questions.