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 ;) )
Friday, October 27, 2006
GLOverlay
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 ;) )
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 ;) )
Tuesday, October 24, 2006
Disappointing
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.
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.
Monday, October 23, 2006
Benchmarks
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.
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.
Thursday, October 19, 2006
ARGB windows
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.
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.
Saturday, October 07, 2006
Bands
I've been browsing youtube today and I was pretty suprised to find some hardcore music videos on it. I've spent a little time just looking for bands that I enjoy listening to. So, in no particular order, here's what I am listening to:
Shelter - Here We Go
Throwdown - Forever
Hoods - The King Is Dead
H2O - One Life, One Chance
Madball - Pride
Earth Crisis - Nemesis
Do or Die - Bella Famiglia
Sick Of It All - District
Ramallah - The Horror
E-Town Concrete - Mandibles
Warzone - The Sound of Revolution
Hatebreed - Perseverance
Terror - Overcome
The ending of Throwdown's Forever when he says:
"For myself,
For my friends,
For my family,
Straight fucking Edge!" is just such a great breakdown.
Shelter - Here We Go
Throwdown - Forever
Hoods - The King Is Dead
H2O - One Life, One Chance
Madball - Pride
Earth Crisis - Nemesis
Do or Die - Bella Famiglia
Sick Of It All - District
Ramallah - The Horror
E-Town Concrete - Mandibles
Warzone - The Sound of Revolution
Hatebreed - Perseverance
Terror - Overcome
The ending of Throwdown's Forever when he says:
"For myself,
For my friends,
For my family,
Straight fucking Edge!" is just such a great breakdown.
Friday, October 06, 2006
Perspective transformations in main
Today I merged qt-perspective branch into qt-main. Yesterday I fixed some issues with bilinear filters and some minor stroking artifacts and decided that perspective transformations are ready for main stream. We're hoping to switch snapshots to 4.3 very soon which will allow everyone who considers 4.2 way too stable something pretty unstable to play with =) Of course the main purpose of perspective transformations is to make things like the 3D album selection in iTunes. That's trivially doable in Qt now :)
I switched QGraphicsView to use QTransform which means that items on QGraphicsView can have perspective transformations. As always a bunch of screenshots follows (I know that some planets don't play nicely with blogspot so you might have to just come to blogspot.com and refresh to see them)
All of those are trivially doable in Qt without any OpenGL calls. It's really extremely nice and I must admit I spent most of today playing with it and writing demos. (Oh, and because it happens over and over again, please pay no attention to the fps field, when I'm implementing new features I always test corner cases and the fps on my examples are always skewed because they test something very different than what the the screenshots would imply. Whenever I post screenshots I keep forgetting to mention that and there's always someone who gets bogged down by it so now you've been warned :) You'll have to get 4.3 snapshots if you'll want to see how well it works).
I switched QGraphicsView to use QTransform which means that items on QGraphicsView can have perspective transformations. As always a bunch of screenshots follows (I know that some planets don't play nicely with blogspot so you might have to just come to blogspot.com and refresh to see them)
All of those are trivially doable in Qt without any OpenGL calls. It's really extremely nice and I must admit I spent most of today playing with it and writing demos. (Oh, and because it happens over and over again, please pay no attention to the fps field, when I'm implementing new features I always test corner cases and the fps on my examples are always skewed because they test something very different than what the the screenshots would imply. Whenever I post screenshots I keep forgetting to mention that and there's always someone who gets bogged down by it so now you've been warned :) You'll have to get 4.3 snapshots if you'll want to see how well it works).
Subscribe to:
Posts (Atom)