Linked by Thom Holwerda on Wed 5th Aug 2009 00:12 UTC, submitted by rexstuff
KDE The KDE team has released KDE 4.3. This release comes packed with improvements and bug fixes - in fact, over the last six months, 10000 bugs were squashed, 2000 feature requests handled, and 63000 changes were checked in by 700 people. We've already talked about this new release in quite some detail last week, but let's take a look at the most important new features anyway.
Thread beginning with comment 377058
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Great!
by siride on Wed 5th Aug 2009 01:28 UTC in reply to "RE[2]: Great!"
siride
Member since:
2006-01-02

That does explain slow redraws during exposures and other similar behavior. And I'm sorry, I don't buy the window resizing excuse. I can smoothly and quickly resize KDE 3.5 app windows. There are no missing frames. The entire window is clearly updated for a number of steps and very quickly. Relayout is instantaneous. Not so with Qt 4, which seems to take forever to do relayout. And even if X does send too many resize messages because there is no throttling, that's no excuse. I have a fast computer. There's no reason why relayout and redraw should take so very long. Every other OS can handle resizing just fine...it's smooth and relayout is instantaneous (with the exception of a few poorly written apps).

I'm tired of the excuses. Qt4 and GTK+ are just plain slow and there's no getting around that. And to top it off, while KDE 3.5 and to some extent GTK+ apps have been getting faster on my machine as my X drivers and server improve, Qt 4 has gone considerably slower. That just doesn't make sense. Somebody is screwing up.

Reply Parent Score: -2

RE[4]: Great!
by Elv13 on Wed 5th Aug 2009 01:39 in reply to "RE[3]: Great!"
Elv13 Member since:
2006-06-12

ATI driver have a problem with 4.3. Who is responsible is yet to be clear. About other resizing bug, as I said in that post, "normal" resizing protocol is time based, not direct. KDE3 and Gnome2 use(d) an hack to have pixel per pixel resize. It is not part of X protocol and is inofficial, but Qt 4.6 will support that walk around protocol. So it is not really Qt/KDE problem, but it is just how resize should behave on Linux, even if it look slow.

Reply Parent Score: 2

RE[5]: Great!
by JesseWagner on Wed 5th Aug 2009 02:58 in reply to "RE[4]: Great!"
JesseWagner Member since:
2009-02-17

Part of software engineering is getting a desired out of sometimes suboptimal components. Sounds like they should have implemented the hack and the correct way to do it and used the build system to check if the proper way was supported.

Reply Parent Score: 3

RE[4]: Great!
by lemur2 on Wed 5th Aug 2009 02:33 in reply to "RE[3]: Great!"
lemur2 Member since:
2007-02-17

I'm tired of the excuses. Qt4 and GTK+ are just plain slow and there's no getting around that. And to top it off, while KDE 3.5 and to some extent GTK+ apps have been getting faster on my machine as my X drivers and server improve, Qt 4 has gone considerably slower. That just doesn't make sense. Somebody is screwing up.


Your machine wouldn't have Intel graphics by any chance would it?

http://www.phoronix.com/scan.php?page=article&item=intel_q309_flake...

On my test machine, KDE 4.3 is faster than any previous version of KDE (including KDE 3 series) and faster than GNOME.

Edited 2009-08-05 02:35 UTC

Reply Parent Score: 5

RE[5]: Great!
by siride on Wed 5th Aug 2009 02:37 in reply to "RE[4]: Great!"
siride Member since:
2006-01-02

I have ATI Radeon Mobility X300 (r300) with 64 MB of video memory. It's really pretty performant...except when it comes to Qt4. Of course Windows flies, but that's to be expected since they actually know how to write a performant graphics system.

Reply Parent Score: 3

RE[4]: Great!
by bnolsen on Wed 5th Aug 2009 03:58 in reply to "RE[3]: Great!"
bnolsen Member since:
2006-01-06

QT4 over engineered their rendering engines. They did it to get all the fancy effects like AA, composing, etc. Unfortunately they tanked their performance for CAD type applications and pretty much tossed any hope of running remote display/remote terminal applications.

It's a shame and probably all this stuff needs to be ripped out, refactored and dramatically simplified, like the whole rest of QT.

Reply Parent Score: 4

RE[5]: Great!
by Messere on Wed 5th Aug 2009 06:26 in reply to "RE[4]: Great!"
Messere Member since:
2006-10-12

QT4 over engineered their rendering engines. [...] and pretty much tossed any hope of running remote display/remote terminal applications.


So true.

NX client connected to kde4 is unbearably slow compared to kde3 on the same network link. And it gets even worse with "raster" rendering enabled.

Reply Parent Score: 4

RE[5]: Great!
by superstoned on Wed 5th Aug 2009 09:20 in reply to "RE[4]: Great!"
superstoned Member since:
2005-07-07

Over engineered - well, yes, that's one way of looking at it. You could also say they developed a rendering engine capable of using the latest hardware acceleration features available. Those features (still) don't work properly on linux (no problem on win and mac, btw) so now it's up to the X.org devs and driver developers to fix their software.

KDE isn't an operating system, you know. We build upon what is provided by the platform - and if the platform provides a sucky infrastructure, our performance suffers. And in the interest of moving forward, we refuse to work around bugs in the lower stack - we'd rather see them fixed. Sorry for that but we believe progress needs a strong platform. And those features we're gonna need in the future won't be done properly i we don't put some pressure on those working on it.

Reply Parent Score: 15