EFYTimes has an interview with Matthias Ettrich, one of KDE's founders. He talks about the history of the project, what he thinks of KDE 4.0 and what he's currently working on in Qt. "The desktop problem has been solved many years ago. Try to compare Windows XP with KDE 3: nobody in their right mind would choose Windows over GNU/Linux based on the desktop experience alone."

I think, (no really I hope thay do, otherwise I'm doing it myself! :-) they might be using Qt Jambi as basis for a recently introduced mobile framework .....
What do you think?? :D
Using Qt Jambi for it could allow a fast framework implementation on top of very different hardware, and again shorten the time-to-market for mobile devices.

But in Qt4 there is implicit sharing of most basic classes which makes it use less memory, so logically, it uses less memory. It is of course also dependant on how you use Qt4, but even programmers who don't care about how many copies they make of some 'QString' or whatever, will use less memory because of this sharing.

So if KDE4 uses more memory, then I think that to build the same thing with KDE3, you would use even more memory :)

"But in Qt4 there is implicit sharing of most basic classes which makes it use less memory, so logically, it uses less memory."

No, because you're ignoring the portions of Qt4 that use far more memory than Qt3. The most important of these is double-buffering of *all* widgets, *all* the time. By way of demonstration: A single Kwrite window is nearly all widgets. On a 32-bit 1600x1200 monitor, the double-buffering for our Kwrite Window will take up a little under 4 bytes * 1600 * 1200 ~ 7.5 *megabytes*. There's no way that Qt4's meagre savings in strings and QObjects will even come close to this, and so we are in the situation of having a text editor use many megabytes more than its Qt3/KDE3 counterpart. Open 5 kwrite instances, and you are gobbling up a ludicrous *35MB* *just* for the double-buffering on the widgets.

Qt4's so-called "optimisations" are one of the best examples of the phrase "Penny wise, pound foolish" imaginable.

Note that the buffering occurs only near the paint events. Unless I have missed something, and unless you have 5 displays: you do not have all the windows maximized and displayed/redrawn in the same time. Moreover, aren't paint events limited to rectangle regions, e.g. in KWrite: to the line where you're typing your text?

No, unfortunately they are buffered continuously - even if they are on a separate desktop and you haven't used them for several hours :/ (As a corollary, it doesn't matter if only a small region of a window is updated.)

If the buffering was only used during paint events and then discarded for widgets that have not been re-painted in a while, then this would be pretty cool and efficient, but that's not the case.

Yes, Qt4 uses more video memory (which isn't difficult because realistically it's really difficult to be using less than 0 which we've been using up until Qt4) but it uses a lot less RAM.
So on systems with dedicated video memory it fallows that Qt uses a lot less memory. At least as far as you as a user of the API are concerned since, obviously, vmem is not where your application/library data is being held.

Hmm. Well on linux the memory used by double buffering shows up in the Xorg process. Don't think this is stored in video memory, unless free is incorrectly counting video memory.

In one sense, double buffering is great. It removes most UI flicker without any effort on the part of the application devs. For my own commercial Qt development, it is a huge advantage. But on the other hand, the cost is quite large when every app you run is completely double buffered, and it doesn't seem really necessary all the time. For example, not all widgets suffer from flicker in Qt3. It's really only things like a file view in a file manager or some other complex widgets. And yet in Qt4, every single widget is double buffered, with the corresponding memory cost.

And the problem is, turning off double buffering in Qt4 globally turns any Qt4 app into a huge flickering mess, with every single widget flickering like crazy, even widgets like menus and toolbars that don't flicker on Qt3 or GTK. So what's the difference? Did Qt3 manually double buffer those widgets?

Qt 3 had some tricks to reduce flicker without double buffering (for example, there used to be a "bool noErase" parameter to QWidget::repaint), which have been dropped in Qt 4 because double buffering is now used.

"""And the problem is, turning off double buffering in Qt4 globally turns any Qt4 app into a huge flickering mess, with every single widget flickering like crazy, even widgets like menus and toolbars that don't flicker on Qt3 or GTK. So what's the difference? Did Qt3 manually double buffer those widgets?"""

Yep I've done this before on some special widgets, like one that displays frames from a camera.

However I just did an experiment on an app I'm working on. The biggest memory cost is obviously the main window widget itself. It has a huge double buffering pixmap, and takes the most memory. So what happens if you disable double buffering on just the main widget, but leave it enabled on all others?

Well, on the plus side, there is no added flicker, even if you disable double buffering on the main widget. All the widgets that actually would flicker, like buttons, menus, checkboxes, etc. are still double buffered, so the UI is just as nice as before. And the vast majority of the memory hit is gone. A maximized window takes about 6mb less Xorg memory when I disable double buffering on the main window.

However, there is one downside. Widgets that are transparent now have a grey background instead. So checkboxes have a grey rectangle background instead of letting the default style background show through. This is with the oxygen style.
If you choose the Plastique style instead, then everything looks much better. Because the window background is grey anyway, the fact that checkboxes are not transparent is irrelevant. So in this case you get the 6mb of ram back for basically free. Not really a realistic option for most apps, but hey..

I attached a comparison screenshot of the same app running with double buffering disabled on the main widget, using the oxygen and the plastique style to see the difference.

Sounds like a great idea, since lots of windows are there as a container for other widgets. In my little extra gear project, the main window is completely covered with dock windows.
However with qt4.4 coming soon, there is only one native window and thus one double buffer. Just tried it with trunk and indeed the app looks completely broken with setAttribute(Qt::WA_PaintOnScreen);, docks aren't updated properly neither is the menubar and statusbar.

What is the double buffering for anyway? If I look at the poor way windows and widgets are drawn at the moment (I'm referring to 4.0.2), I don't expect double buffering there. Or am I missing something?

The poor way windows are drawn? Can you elaborate? They are drawn nicely here.

Every widget is double buffered in Qt4, and by extension KDE4. For example, dragging a window in front of a dolphin's file view does not cause any flicker as the file view refreshes, as it used to in KDE3.

With "poorly drawn" I mean that I can see the window redrawing on a maximizing/restore/minimize in a very shaky way, and no compositing effects are smooth animations, even doing something simple like selecting file->new for example in any kde4 program makes that file menu pop up, then it disappear, then it is redrawn again, which is killing my user experience. And all that while my gfx card (a GeForce8600M) obviously can (and does) run compiz smoothly (except for fsaa, but that's another problem altogether anyway).

If you compare application to application, a simple one, you'll find that it does take less memory. That's what my tests indicated, by counting the marginal memory usage after the desktop libraries was already loaded (using /proc//smaps). My testcase was kwrite.

Two things make it VERY hard to say that "KDE 4 uses less memory than KDE 3":

1) it's not a fair comparison, since the features and services are very different. The experience with KDE 4 is much different from KDE 3. If you really want low memory usage and you're not worried about new features and bugfixes, you can keep using a very old KDE version, or even DOS...

2) it's very difficult to account for memory usage for more than one application. One is easy because you know what is not shared with anyone else. With two or more, you have to ask: what is shared between those applications? And how many pages? We currently don't have the answer for that, but Andrew Morton (kernel developer) mentioned that 2.6.25 will contain a better interface to do just that.

In any case, the 40% figure came from a user that, while well-intentioned, had very little clue about what he was doing. What amazes me is that the press and the public keep referring to those numbers even after we publicly debunked them.

You'll notice that Matthias did not confirm the numbers. He's aware of memory efficiency improvements in Qt 4 and KDE 4 code, but he'll not vouch for a hard number like 40%.

In an addition to the fellow mentioning the extra mem usage of double buffering.
You'll find this in this in the memory of the Xserver not in /proc//smaps of the app, as this typically is done using XPixmaps.

I'm not really complaining about memory usage. More advanced frameworks use more resources. That's just the way things go. But due to double buffering, the same app on Qt4 will use more memory than using Qt3. The process itself might take less, but the cost of double buffering easily erases that small advantage.

And looking at the memory usage of the full desktop running typical apps, it is definitely much more than in KDE3. Like I said, I'm not complaining, but I don't think anyone would seriously argue that it is the case.

"Its funny how one incorrect and quickly redacted measurement can convince so many people. KDE 4 certainly does not take less memory than KDE 3, and I don't think that myth is doing anyone any favours."

Hmmmmmmmmmmmm. Does that mean that KDE 4 does more than KDE 3 and uses more memory, or that when comparing KDE 4 and KDE 3 doing the same things KDE 4 uses less memory.

The impact depends largely on the screen size. On my EeePC, an empty KDE4 session uses about 10mb more than an empty KDE3 session. On my work comp (1680x1050 display), the difference is much larger (~50 mb IIRC).

It is not meaningless at all, as long as you look at the line that subtracts the buffers/cache.

In fact, this is the most meaningful measure of memory for the user, because as a user I'm mostly interested in "How much memory do I have left for applications", and measuring total used memory gives that answer, without having to worry about complexities like how much of a process's used memory is shared.

What you don't understand is that I'm not even remotely interested in exact memory usage. I don't care if the value that free reports is +- 10%. Free may not be the most accurate, but it's not random. The values correlate with memory usage, and it's pretty clear that KDE4 uses more. I could remeasure with exmap, but I would get the same conclusion so I really don't care.

Its a good interview, one of the best in awhile. Though, I'm concerned on how bias he was when answering questions.

"The desktop problem has been solved many years ago. Try to compare Windows XP with KDE 3: nobody in their right mind would choose Windows over GNU/Linux based on the desktop experience alone."

When I had Kubuntu installed with KDE 3.5 and a regular 15 year old friend over. He started to get frustrated while using KDE and wanted to use XP again and luckily I had a duel boot. It shows something, though hopefully he will have better reviews with KDE 4 but until alot of people like XP. There have been others, I have two other friends that hate when I have linux installed.

Also, can't wait for that hidden project. I hate how he said that, thats one irritating tease.

> He started to get frustrated while using KDE and wanted to use XP again

That's not choosing XP based on the desktop experience alone. Your friend presumably wanted XP because he was familiar with it and wasn't with KDE. That's not 'desktop experience alone', just like e.g. hardware support or number of games available are not.

The article is a bit stupid. For example, compare XP with KDE 3. Xp is what, 7 years old. Of course kde 3. is better than such an old platform. But, still with XP you can use more technology than with KDE, so if given the choice, if I wanted a computer that performed with high quality software I would go with XP, because at the moment the linux applications are still the major let down to linux.