"Commitment" is one of the words that have never been used in this blog. Which is pretty impressive given that I've managed to use such words as sheep, llamas, raspberries, ninjas, donkeys, crack or woodchuck quite extensively (especially impressive in a technology centric blog).
That's because commitment implies that whatever it is one is committed to plays an important role in their life. It's a word that goes beyond the paper or the medium on which it was written. It enters the cold reality that surrounds us.
But today is all about commitment. It's about commitment that KDE made to a technology broadly refereed to as Scalable Vector Graphics. I took some time off this week and came to Germany where I talked about usage of SVG in KDE.
The paper about, what I like to call, the Freedom of Beauty, is available here:
https://www.svgopen.org/2008/papers/104-SVG_in_KDE/
It talks about the history of SVG in KDE, the rendering model used by KDE, it lists ways in which we use SVG and finally shows some problems which have been exposed by such diverse usage of SVG in a desktop environment. Please read it if you're interested in KDE or SVG.
Hopefully this paper marks a start of a more proactive role KDE is going to be playing in shaping of the SVG standard.
Thursday, August 28, 2008
Tuesday, August 26, 2008
Fixes in Sonnet
As we all know inner beauty is the most important kind of beauty. Especially if you're ugly. Not ugly, don't sue me, I meant to say "easy on the eyes challenged". That's one of the reasons I like working on frameworks and libraries. It's the appeal of improving the inner beauty of certain things. I gave up on trying to improve the inner beauty of myself (when I was about 1) so this is the most I can do.
You can do it too. It's real easy. I took this week off because I'm going to Germany for SVG Open where I'll talk about SVG in KDE and today fixed a few irritating bugs in Sonnet.
One of the things that bugged me for a while was the fact that we kept marking misspelled text as red instead of using the God given red squiggly underline. Well, I say no more!
Our spelling dialog lists available dictionaries now and one can change them on the fly. That's good. Raspberries good. And raspberries are pretty darn good. Even sheep like raspberries. Or so I think, the only sheep I've ever seen was from a window of a car and it looked like an animal who enjoys raspberries. Who doesn't? The only problem was that it liked listing things like "en_GB-ise" or "en_GB-ize-w_accents" as language names which is really like a nasty bug in the raspberry. And what do you with bugs? I'm not quite certain myself but given the way this blog is heading it's surely something disturbing... Anywho. that's also fixed. Now we list proper and readable names. As in:
Working on Sonnet is a lot of fun. A small change in a pretty small library affects the entire KDE which is rather rewarding. So if you wanted to get into KDE development in an easy and fun way go to https://bugs.kde.org search for "kspell" or "sonnet" pick an entry and simply fix it!
You can do it too. It's real easy. I took this week off because I'm going to Germany for SVG Open where I'll talk about SVG in KDE and today fixed a few irritating bugs in Sonnet.
One of the things that bugged me for a while was the fact that we kept marking misspelled text as red instead of using the God given red squiggly underline. Well, I say no more!
Our spelling dialog lists available dictionaries now and one can change them on the fly. That's good. Raspberries good. And raspberries are pretty darn good. Even sheep like raspberries. Or so I think, the only sheep I've ever seen was from a window of a car and it looked like an animal who enjoys raspberries. Who doesn't? The only problem was that it liked listing things like "en_GB-ise" or "en_GB-ize-w_accents" as language names which is really like a nasty bug in the raspberry. And what do you with bugs? I'm not quite certain myself but given the way this blog is heading it's surely something disturbing... Anywho. that's also fixed. Now we list proper and readable names. As in:Working on Sonnet is a lot of fun. A small change in a pretty small library affects the entire KDE which is rather rewarding. So if you wanted to get into KDE development in an easy and fun way go to https://bugs.kde.org search for "kspell" or "sonnet" pick an entry and simply fix it!
Wednesday, August 20, 2008
Fast graphics
Instead of highly popular pictures of llamas today I'll post a few numbers. Not related to llamas at all. Zero llamas. These will be Qt/KDE related numbers. And there's no llamas in KDE. There's a dragon, but he doesn't hang around with llamas at all. I know what you're thinking: KDE is a multi-coltural project surely someone must be chilling with llamas. I said it before and I'll say it again, what an avarage KDE developer, two llamas, one hamster and five chickens do in a privacy of their own home is none of your business.
Lets take a simple application, called qgears2, based on David Reveman cairogears and see how it performs with different rendering backends. Pay attention to zero relation to llamas or any other animals. The application takes a few options, -image: to render using a CPU based raster engine, -render: to render using X11's Xrender and -gl to render using OpenGL (-llama option is not accepted). It has three basic tests, "GEARSFANCY" which renders a few basic paths with a linear gradient alpha blended on top, TEXT that tests some very simple text rendering and COMPO which is just compostion and scaling of images.
The numbers come from two different machines. One is my laptop which is running Xorg server version 1.4.2. Exa is 2.2.0. Intel driver 2.3.2. GPU is 965GM, CPU is T8300 at 2.4GHz running on Debian Unstable's kernel 2.6.26-1.
The second machine is running GeForce 6600 (NV43 rev a2), NVIDIA proprietary driver version G01-173.14.09, Xorg version 7.3, kernel 2.6.25.11, CPU is Q6600 @ 2.40GHz (thanks to Kevin Ottens for those numbers, as I don't have NVIDIA machine at the moment).
The results for each test are as follows:
COMPO test isn't really fair because as I mentioned Qt doesn't use server side picture transformations with Xrender but it shows that OpenGL is certainly not slow at it.
So what these results show is that GL backend, which hasn't been optimized at all, is between 2 to 6 times faster than anything out there and that pure CPU based Raster engine is faster than the Xrender engine.
So if you're on an Intel GPU, or NVIDIA GPU rendering using GL will immediately make your application a number times faster. If you're running on a system with no capable GPU then using raster engine will make your application faster as well.
Switching Qt to use GL backend by default would result in all applications running a magnitude times faster. The quality would suffer though (unless HighQualityAntialiasing mode would be used in Qt in which case it would be the same). This certainly would fix our graphics performance woes and as a side-effect allow using GL shaders right on the widgets for some nifty effects.
On systems with no GPU raster engine is a great choice, on everything else GL is clearly the best option.
Lets take a simple application, called qgears2, based on David Reveman cairogears and see how it performs with different rendering backends. Pay attention to zero relation to llamas or any other animals. The application takes a few options, -image: to render using a CPU based raster engine, -render: to render using X11's Xrender and -gl to render using OpenGL (-llama option is not accepted). It has three basic tests, "GEARSFANCY" which renders a few basic paths with a linear gradient alpha blended on top, TEXT that tests some very simple text rendering and COMPO which is just compostion and scaling of images.
The numbers come from two different machines. One is my laptop which is running Xorg server version 1.4.2. Exa is 2.2.0. Intel driver 2.3.2. GPU is 965GM, CPU is T8300 at 2.4GHz running on Debian Unstable's kernel 2.6.26-1.
The second machine is running GeForce 6600 (NV43 rev a2), NVIDIA proprietary driver version G01-173.14.09, Xorg version 7.3, kernel 2.6.25.11, CPU is Q6600 @ 2.40GHz (thanks to Kevin Ottens for those numbers, as I don't have NVIDIA machine at the moment).
The results for each test are as follows:
| I965 | NVIDIA | |
|---|---|---|
| Xrender | 35.37 | 44.743 |
| Raster | 63.41 | 41.999 |
| OpenGL | 131.41 | 156.250 |
| I965 | NVIDIA | |
|---|---|---|
| Xrender | 13.389 | 40.683 |
| Raster | (incorrect results) | (incorrect results) |
| OpenGL | 36.496 | 202.840 |
| I965 | NVIDIA | |
|---|---|---|
| Xrender | 67.751 | 66.313 |
| Raster | 81.833 | 70.472 |
| OpenGL | 411.523 | 436.681 |
COMPO test isn't really fair because as I mentioned Qt doesn't use server side picture transformations with Xrender but it shows that OpenGL is certainly not slow at it.
So what these results show is that GL backend, which hasn't been optimized at all, is between 2 to 6 times faster than anything out there and that pure CPU based Raster engine is faster than the Xrender engine.
So if you're on an Intel GPU, or NVIDIA GPU rendering using GL will immediately make your application a number times faster. If you're running on a system with no capable GPU then using raster engine will make your application faster as well.
Switching Qt to use GL backend by default would result in all applications running a magnitude times faster. The quality would suffer though (unless HighQualityAntialiasing mode would be used in Qt in which case it would be the same). This certainly would fix our graphics performance woes and as a side-effect allow using GL shaders right on the widgets for some nifty effects.
On systems with no GPU raster engine is a great choice, on everything else GL is clearly the best option.
Tuesday, August 19, 2008
Difference between working and usable
During the last few days I've read a lot of articles about Firefox Qt. I've had a hunting "I've been through this" feeling while reading all of them.
Ars Technica used the following picture to show that it's working:
If there's anything that I'm excited about it's the fact that the initiative came from Mozilla guys not from an outside group. A few years back when Lars and I did the Qt Mozilla port one thing we've realized very quickly is that due to some politics and time constrains on our part there's no way we could maintain that code. We have been talking about it and one of the conclusions was that the port will not succeed unless it's started from within Mozilla itself. Like this port certainly has.
Unfortunately it's not writing code, it's making it work and maintaining it that are the difficult parts. All the articles saying that there's Qt Firefox are just wrong. Code has been written that might allow Qt Firefox to be usable at some point, but just looking at that screenshot shows there's tons of work to be done before that happens.
In general I just don't think that Qt and Mozilla are meant to be mixed. There's ton of duplication all over the place. Qt has a GUI language, Mozilla has a GUI language, Qt is a toolkit, Mozilla has its own toolkit, Qt has networking library, Mozilla has a networking library, Qt has a JS engine, Mozilla has a JS engine, Qt comes with QtWebKit, Mozilla comes with Mozilla... Unless there's some kind of a discussion about integrating those parts then, especially in embedded scenarios, that duplication is far from optimal. I also think that while Qt Firefox port coming from within Mozilla itself 3 years ago would have all Qt/KDE developers compiling it within minutes, that window has closed with the release of QtWebKit in Qt 4.4. Qt/KDE community already has engines they're committed to (Qt engineers have WebKit and KDE engineers either WebKit or KHTML) so the code won't get any community traction from Qt/KDE developers and Mozilla guys will be left having to maintain it themselves.
I think it's certainly a great effort but I doubt the code can get anywhere without support from Qt/KDE community and realistically when talking about web in the the Qt/KDE circles Gecko doesn't even enter the discussion. Not even getting into a discussion about code quality and familiarity with it, big reason for that is that for KDE bug-for-bug compatibility with OS X, despite Mozilla's greater market share, provides a lot more attractive proposition due to similarity of usage of web engines in both environments, e.g. Dashboard widget compatibility. So all in all, great project, just a little too late.
Ars Technica used the following picture to show that it's working:
If there's anything that I'm excited about it's the fact that the initiative came from Mozilla guys not from an outside group. A few years back when Lars and I did the Qt Mozilla port one thing we've realized very quickly is that due to some politics and time constrains on our part there's no way we could maintain that code. We have been talking about it and one of the conclusions was that the port will not succeed unless it's started from within Mozilla itself. Like this port certainly has.
Unfortunately it's not writing code, it's making it work and maintaining it that are the difficult parts. All the articles saying that there's Qt Firefox are just wrong. Code has been written that might allow Qt Firefox to be usable at some point, but just looking at that screenshot shows there's tons of work to be done before that happens.
In general I just don't think that Qt and Mozilla are meant to be mixed. There's ton of duplication all over the place. Qt has a GUI language, Mozilla has a GUI language, Qt is a toolkit, Mozilla has its own toolkit, Qt has networking library, Mozilla has a networking library, Qt has a JS engine, Mozilla has a JS engine, Qt comes with QtWebKit, Mozilla comes with Mozilla... Unless there's some kind of a discussion about integrating those parts then, especially in embedded scenarios, that duplication is far from optimal. I also think that while Qt Firefox port coming from within Mozilla itself 3 years ago would have all Qt/KDE developers compiling it within minutes, that window has closed with the release of QtWebKit in Qt 4.4. Qt/KDE community already has engines they're committed to (Qt engineers have WebKit and KDE engineers either WebKit or KHTML) so the code won't get any community traction from Qt/KDE developers and Mozilla guys will be left having to maintain it themselves.
I think it's certainly a great effort but I doubt the code can get anywhere without support from Qt/KDE community and realistically when talking about web in the the Qt/KDE circles Gecko doesn't even enter the discussion. Not even getting into a discussion about code quality and familiarity with it, big reason for that is that for KDE bug-for-bug compatibility with OS X, despite Mozilla's greater market share, provides a lot more attractive proposition due to similarity of usage of web engines in both environments, e.g. Dashboard widget compatibility. So all in all, great project, just a little too late.
Subscribe to:
Posts (Atom)
