Kde 3.1.1 has been released today. Here is the announcement and the Changelog.
KDE 3.1.1 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Kde 3.1.1 has been released today. Here is the announcement and the Changelog.
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
The best yet even better. From own experience I can tell that the CVS is under HEAVY development and CVS HEAD is much more cleaned up than 3.1 was. Control Center is really clean now. Kaplan is on it’s way to become a really mature OutLook derivate. It’s fun and pleasing to use this consistent, clean Desktop Environment. Thumbs up for the Developers. There is nothing similar on Linux as Desktop Environment.
So how’s the performance? Still as slow as before, or is there some improvement.
Imho, both KDE and GNOME are far too slow to be usable (at least on my pIII 850, perhaps on your killer system they’re faster, but…). So is it worth another try, or should I just stick to blackbox/fvwm/… and _fast_ browsers like dillo and links?
slow on a p800?
I am using gnome 2.2.1 on a p3 450 w. 128mb ram.. and the same setup on my ibook. (tangerine 1:st gen ibook, 333mhz g3 w. 128mb ram)
albeit im using gentoo & gentoo ppc, i wonder why it is slow on your box?
KDE 3.1 is FAST!
Very fast!! Much faster than previous versions.
I tried Redhat 8’s latest beta (phoeba) and found their Gnome setup to be significantly slower than KDE 3.1. At least as far as normal GUI things goes (opening apps, unhiding and rehiding elements, etc).
Man… And it seems like just yesterday that 3.1.0 came out. Good work KDE guys!
So is it worth another try, or should I just stick to blackbox/fvwm/… and _fast_ browsers like dillo and links?
Well, from my experience KDE isn’t slow, but my machine is pretty fast (Athlon XP 1900+ w/ 512 MB PC2700 RAM). If you are liking blackbox right now then why change (unless you aren’t satisfied with it)? I say if it’s not broke, don’t fix it.
Another thing you may want to do is track down any excessive daemons and processes that could be slowing you down. I know certain distributions *cough* Redhat *cough* can be pretty liberal about what processes run by default.
By the way, it looks like the ebuild for this is already marked stable. Hooray!
I am now aptituding it. Great that it is available as binary so fast!
Gnome and KDE are both speedy on my P600, my P400, my P300, my AMD 400, my P500, and my P1.6.
“khtml: Several major bugfixes, partially incorporated fixes from Safari as well.”
I wonder when are we going to see a Win32 khtml-browser?
I prefer KDE over GNOME, but man, why don’t you quit your blind KDE cheerleading! For your information, KDE still has serious problems (and frankly, Eugenia was too kind!) – I haven’t tried 3.1.1, but you are not doing any good with cheerleading. Why don’t you try to identify the problems and contribute some code, that’s far more useful then screaming KDE is perfect, because KDE IS NOT (Gnome even worse).
I’m glad to see that Konqueror is starting to adopt some of the Safari changes. I like the rendering in Safari on my OS X box much more than the rendering in Konqueror on my Mandrake box. Can’t wait to install it!
“Imho, both KDE and GNOME are far too slow to be usable (at least on my pIII 850, perhaps on your killer system they’re faster, but…”
Errr huh? Your PC must be broken. KDE and more so GNOME when you leave all the eyecandy stuff on, are akin to XP in speed. XP runs fine on a PIII 850. All you need is 256MB ram and on a PIII 600 or above all x86 OS’s run fine. I run Red Hat 8.0 on a PIII 700 laptop with a pathetic 4200rpm hard drive and it runs fine and I notice no difference is responsiveness between Gnome and XP.
BTW people who want the latest OS’s and apps to run great on 5 year old hardware need to be a little more realistic. If your still running a PII 300 with 128MB ram time to freaking upgrade to something made in the 21st century. That or stick with an old OS or run a lightweight Windows Manager. There will never be a release of KDE or Windows that is going to make that old hardware seem fast, so deal with it.
I prefer KDE over GNOME, but man, why don’t you quit your blind KDE cheerleading! For your information, KDE still has serious problems
And for “my” information, what are those ‘serious problems’?!
for the big changes from safari you have to wait for kde3.2
KDE is usable on my system, but nothing more. It is a P350 with 64 MB ram. Kdvi is a hell, though, as it takes 55 mB.
The biggest speed problem with KDE is the memory. Here kde works quite slow as it needs to swap so often. Not because the processor load is so high.
This is finally typed on KDE 3.1.1, after having had some installation problems. The debian packagers seem to merge more and more packages, causing conflicts now and then. Removing conflicting packages is not possible without forcing, as the old KDE programs depend on those old libraries, but after forced removal of the problematic packages everything is right now.
At first glance, I do not see any differences, but what would you expect from a minor update.
Read Eugenia’s desktop comparison remarks on KDE to start with – although I personally haven’t had the instability probs with Konq she did, KDE has serious usability problems (Kmenu is a mess – and I’m not saying strip everything like Gnome, but please put some intelligence in organizing the thing better). That’s just a start – it wouldn’t matter, if not for the fact that it doesn’t seem as if the developers are even aware of the problem and trying to fix it, or intend to in the future.
I am currently working on KDE 3.0.1 in Suse 8.1. It loads very fast and responsive. I am amazed that it loads quick on thin client, which I am using right now.
Over here, my KDE 3.1 is quite fast. Not BeOS-fast, but WinXP fast. Of course, I’m using a 2GHz P4 with 640MB of RAM. Specifically what do you find slow about it? App startup is quite slow (on my system too, it’s a C++ thing) but that is largely resolved by running prelinking. Unfortunately, only a few distros (Gentoo is the only one I can think of ATM) that support it out of box. However, right now there is a conflict between the NVIDIA drivers and prelinking, so it’s not useful to the large number of NVIDIA Linux users. Redraw is mixed. On well optimized applications (QT Designer, KWord) it’s better than WinXP. On less optimized applications (Konqueror) it’s worse. However, do note that the “resize window” benchmark is apparently quite misleading, because X11 apps have some pathalogical problems with respect to resizing behavior. Other than that, I’m at a loss. What else is there?
“””And for “my” information, what are those ‘serious problems’?!”””
On my end with 3.1 I’ve had significant stability issues with Konq and noatun (so much so that Konq isn’t usable as a webbrowser and noatun isn’t usable at all), the gui flickers/takes excessive redraw time (constantly it’s rather annoying). This is on a PIII-700 with 256 Megs of Ram and with KDE compiled with gcc 3.2
Well I am following and regulary compiling KDE from CVS since pre 3.0 release till NOW and I do get some segfaults of Konqueror myself during browsing every now and then but I know where these issues are comming from and I can live with that. It’s simply the nature of software and the nature of CVS. Regardless how stable the System runs and how stable the compiler and linkers are.
I must tell you that I have more issues with GNOME being unstable such as Anjuta2 crashing during Exit, GStreamer permanently crashing when trying to play anything through alsa09 (devfs) or using Nautilus views crashing when changing the views itself.
What matters here is the overall feel, look and confortability of the System and KDE is quite confortable, overall stable and usable.
i am using kde 3.1 on an old amd processor overclocked to
2.73 gigahertz.
its instant
thats perty fast
I am running GNOME 2.0 on Solaris 9 x86 without any issues, I’d say the majority of the time when people complain its either because they have a pathetic amount of memory or because they haven’t installed the appropriate driver for their video card. In some cases DMA isn’t enabled in some cases due to issues between linux and via chipsets.
So, before coming onto osnews screaming about how KDE or gnome sucks, look at you machine and work out whether it is you and your computer than is the bottle-neck.
It is good to see that KDE 3.1.x speed is improving, much better than 2.x.
I am curious what could be done to improve launch times to almost instantaneous.
Since KDE loves having the features that “everything is configurable”. I would love it if they create a tool with a front end that would allow you to specify which program you would like to be loaded in memory.
For example a window with two columns on the left is a list of applications, on the right a list of the application you would like to have launch in memory. You could add or remove from the list with arrows <<— —>
By having your most used applications already in memory all that would need to be done is draw the window for the apps.
I have a slow machine but with a lot of memory. This would benefit me greatly. I understand it is a hack, but it is a good hack for slow machines.
People say KDE3.1.x is fast but it depends how you use your machine.
To Matthew Gardiner,
People complain how slow Xfree86 and window managers such as Gnome is in linux, how is it in Solaris x86? Does Solaris use a commercial X implementation or xfree86?
Do you get xmms skipping?
Admitted newbie, so the “he probably doesn’t know what he’s talking about” flag is set here.
I’ve noticed, especially with Gentoo, that the inter-relatedness of all the applications, libraries, modules, and the kernel all conspire to make it hard to nail down exactly where the slowdown is. I thought Noatun was crap with all its skippy playback, but trying other apps with the same problem made me think it was KDE itself. Then a friend turned me on to low-latency kernel patches, and I’m having a tough time with that one. Some sites recommend applying them with a pre-emptable kernel, other threads warn against pre-empting. It’s hard to tell which one is right for my system – I have to experiment and run my own stresstests to figure out which configuration is right for my particular machine. Sometimes installing one new thing slows the others down for reasons I can’t fathom. I guess this really *IS* a complex, subtle OS I’m dealing with and not the cobbled-together peice of crap I thought all along.
On the other hand, why can’t it be both complex and subtle AND a peice of crap? It’s a work in progress, guys. Just like every other OS out there.
I suspect that, more than personal subjective measurements, is what’s going on with the various reports I’m seeing on this board. Some people report it’s slow on a GHz machine, others report it’s fast on their PII. It looks to me like some systems are tuned better than others. Not a slight on ya’alls m4d h4x0r sk1zz1llz, you understand. Just a thought.
I’m done fiddling with the kernel, for my part. I’ll wait for Linus and the boys to figure out my latency issues in 2.6.
GMFTatsujin
The performance situation is extremely complex. To tell the truth, I haven’t had a performance disaster (stuff like audio skipping) since I ran a stock kernel on my PII-300. However, there are a number of performance issues that exist today, even on my P4 2GHz running kernel 2.5.65
1) Menu redraw. Menu redraw is just a little less clean than windows. I’d chalk this up to the fact that KDE menus are a whole lot more complex (with icons and everything) than simple text Windows menus. Also, submenus don’t open instantly. I don’t know of this is processing, or a built-in delay, but it is irritating.
2) Text highlighting. I never understood this one. Text highlighting on my P4 2GHz in Konqueror is slower than text highlighting on a P166 running Netscape 4.0. It is noticibly choppy, even on my machine, whereas on the P166 it’s instant. In every app except Konqueror, it’s instant. However, I spend a lot of time in Konqueror, so it really gets to me!
3) Flickering. There is very little flicker left in KDE, most things are now double-buffered. The places that still have it that really annoy me are Konqueror (for history entries while you’re typing in the address bar) and Konqueror in large directories, where icons will flicker as the window is resized(1).
4) Rubber banding. This is perhaps the biggest problem, and is endemic to X apps in general rather than just KDE. Many X apps just don’t handle redraws intelligently. Many visually complex apps have zero rubber banding. These apps include most apps that are composed mostly of KDE widgets, like Kate, most utilities, Qt Designer, Kontrol Center, etc. Other apps, like Konqueror and PixiePlus have extensive rubber banding. Large bitmaps(2) (like those in Kontrol Center) seem to also have rubber-banding problems. Worst of all, gradient toolbars (like in the Keramik theme) will crawl (lag behind the window frame) when resized. It’s an extremely ugly effect, and I actually hacked my version of Keramik to get rid of them.(3) If you just measured window resizing, you’d get a far worse picture of KDE’s (4) performance than is actually the case.
5) App startup. Yes, this sucks. KDE apps seem to have a minimum of a 0.5 second delay built in to process C++ relocations. Prelink reduces this time to 0.01 seconds, and many apps start up almost instantly, but the small size of the x86’s 32-bit address space requires that you run prelink (which can take a few minutes) after installing each app. Linux distros need to bundle prelink by default, have the prelink-regen step built into package installation, and the kernel needs to implement pre-caching(5) like windows.
However, KDE has a number of positive performance points:
1) Consistency. Performance is pretty much the same no matter what you’re doing. I can run two compiles in the background and can’t even tell when they finish because the GUI responsiveness does not change(6). I hate using Windows machines (even XP) because under load the GUI becomes much less responsive. An app crashing (especially IE) can cause the UI to freeze for tens of seconds. In KDE, you can’t even tell an app just died.
2) Flicker. This kind of seems contradictory, but it isn’t. A lot of KDE apps flicker a whole lot less than their Windows counterparts. You can resize Kate like crazy on a giant text file, and it’ll redraw as fast as you move your mouse. Notepad flickers like anything.
Notes:
(1) This directory flicker thing is new. It didn’t used to happen. I have a feeling its due to my 41.x revision of the NVIDIA drivers, which are known to have 2D performance problems. I keep them around because they’re 3D is significantly faster.
(2) Blitting doesn’t seem to be the bottleneck here. X will blit a 500×500 pixmap at 130fps on this machine (during a compile no less). It’s that intelligent redraw again.
(3) This is downright strange behavior. I noticed that if you set Qt to automatically fill the toolbar background, the crawl goes away. So the system is fast enough to fill the region, but the commands don’t get delivered quickly enough.
(4) Interestingly, KDE is a lot better than GNOME with respect to resizing. Stock GNOME widgets (even 2.2.x) will “crawl” when resized. Almost no KDE stock widgets will rubber-band on a resize. In GNOME, most widgets (listviews, text-views, toolbars) will rubberband.
(5) Both Linux and Windows are demand-paged. This means that a page of the executable won’t actually be put into memory until the application actually references it. This causes a whole lot of (expensive) page faults when an application initially loads as it individually loads each page of its working set. Pre-caching records what pages are used by the application immediatly, and loads all of those pages all in one go when the app starts up next time.
(6) On kernel 2.6.65, this feat is achieved with no renice tricks. X is -1 (which is default on most systems), but everything else is stock.
This is all so subjective… I’d almost say that there has to be more than just KDE affecting some of these things. For instance…
1) Menu redraw. Menu redraw is just a little less clean than windows. I’d chalk this up to the fact that KDE menus are a whole lot more complex (with icons and everything) than simple text Windows menus. Also, submenus don’t open instantly. I don’t know of this is processing, or a built-in delay, but it is irritating.
I’m running a 1.2 AMD w/512MB of DDR memory, but I’m also using 2 old video cards to drive a dual monitor setup (An old ATI AIW Pro card, and a Sis 300 based card). Unless I’ve got eye candy to max, with software based transparency, both my menu’s and my submenus open “instantly”. W/transparency on, my submenus open after a very slight delay. So slight in fact that it doesn’t affect usage at all.
The ony way I’ve managed to get a slower submenu going is w/said menu transparency, and opening up say a bookmarks menu that has a ton of bookmarks in the root of the folder (enough to fill the screen of a 21″ monitor). Then I do get a noticable pause, but it’s not so bad that it’s worth turning transparency off IMHO. My workaround was to re-group a lot of my bookmarks under a folder, resulting in less of a delay due to having to display fewer bookmarks.
I’ve also never had the flickering problems you describe. I have noticed that in my Mandrake 9.1 install, icons sometimes get re-drawn poorly when I’m re-sizing windows, but it simply results in a partial re-draw. I think this is unique to Mandrake though as I never experienced it in any of the other distros using 3.1 as their WM.
<i.App startup. [/i]
Again, I think this is tied to distribution… Yoper, Vector, and Redhat8 (Phoebe) all open windows virually instantly. My Mandrake 9.1 RC2 install did not however, which really was a disapointment. Despite all sorts of tweaking, I couldn’t get the response time to go up (as many others have also pointed out, Manndrake 9.1 seems “slow”).
My solution to this was to try reinstalling Mandrake with absolutely nothing selected, and then manually choosing my packages and letting the package manager decide depencies and such.
It took a bit longer to setup this way, but the result is a Mandrake 9.1 install that’s as responsive and quick as my Yoper install was (Vector SoHo 3.2 still seems a tad quicker than Mandrake w/some operations, but generally they’re not equal to one another).
My only thought is that Mandrake was setting up a ton of services (ala Redhat) that slowed my box down. Either way, I now have the responsivness and speed I wanted, but I also have a backend that runs Codeweavers Wine quickly also (something Redhat 8’s latest beta cannot do yet!).
I’m curious if the kernel patches could improve my performance even more. I keep hearing about the “multimedia kernel” included w/Mandrake 9.1, and while I am running said release, I can’t find anything on Mandrakes site, nor in my CD’s which indicates what’s defining the included kernel as a multimedia kernel. My assumption is that it must be a patched kernel, but what patches and why, I do not know (It runs great nonetheless).
Anyone aware of what’s up w/Mandrake 9.1’s kernel? Is it patched, and if not, what patches might boost my responsivness even more?
*** One trick I have learned that really boosts the mouse responsivness up to Windows/Beos level is to increase your mouse sensitivity in your XF86Config-4 file. I’ve seen people increase this to 3000, but I’ve found that 900 is sufficient to really make me feel like I’m using a modern desktop system. Over 900, I really didn’t perceive a difference. Why they don’t do this when the system configured the X-windows system is beyond me.