GTK+ 2.4.3 is a bug fix release and is source and binary compatible with 2.4.0. The main reason for this quick followup release is a problem with the button size allocation logic in 2.4.2, which showed up in the Gimp. A number of other bugfixes have been included as well.
GTK+ 2.4.3 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
You really think it doesn’t perform well? I thought the latest version was noticeably better than previous versions (for everyday use with Gnome anyway — but that could just be that the Gnome code is much improved too).
Mike
It doesn’t on my system.
I think GTK+ users have just gotten used to poor redraw. Just like KDE users have gotten used to slow startup times. I don’t think performance is terribly subjective, when you compare one to the other, but different people have different criteria about what *sorts* of performance are important.
Someday, i’d like to be able to run Gnome on my laptop. Currently, windows XP runs a lot smoother than Gnome.
Pentium 2: 400Mhz
192MB SD-RAM
whats acceptably fast to one will be slow to another. GTK needs to get its redraw problems fixed pronto, its an embarassment. Showing some friend Linux, and you drag a box in front of another…and its gray…for seemingly ever before it updates. It seems…”beta” or unprofessional, not something I’d deem even remotely acceptable. Startup times are fine (for me, but could always use improvement), and other areas are good too insfoar as I can tell. Are there any projects underway to slim up and speed up Gnome and KDE?
Echoing that earlier article, I remember when Linux would install and run /fast/ on machines deemed too old for Windows – what happened? I remember running some of the first versions of Mandrake on my Pentium 133 with 48 megs RAM, it was a 2.2 kernel and KDE 1. 🙂 And it was responsive and quick. How hard would it be to keep the functionality Gnome and KDE has achieved but just slim it up alot? If we could cut memory usage down to half, then I’d count that as a massive victory. Is half unrealistic? What if we did away with as many stupid libraries as possible, or consolidate?
It’s never the “obvious” things that affect performance. Cutting memory usage in half would do almost nothing to improve performance on a decent machine (256-512MB). What *does* impact performance is proper algorithms, and fast code where it counts (display back-ends). It’s not a matter of going in there and slicing up code and rearchitecturing things, but a matter of profiling to find the 10% of the code that is in the hot-path.
Your certainly more knowledgable then me in this, but memory usage would help say an older 32 RAM box, though that may be too low to even be a target for current development. What about 64? At the very least 128 should be plenty, I mean really – some people are now saying you need 1 gig to get a good desktop – thats insane! I remember when 16 megs was /huge/…and despite the gains in eye candy, the basic usage for most users hasn’t really changed in the last decade besides net access and email. Sure, mp3 music and all…but most people still don’t get everything out of their current hardware. I think memory usage does impact performance, if everythings so bloated that a machine with a half gig of RAM is forced to start swapping just minutes into usage…somethings wrong.
“Are there any projects underway to slim up and speed up Gnome and KDE?”
KDE’s 3.2.x series is a significant speed improvement to past releases… though it may not be XP-responsive; it’s a vast improvement from prior 3.x.x releases. Subjectively, I’d say some applications feel anywhere from 15-30% faster—both loading and operating.
And let’s not forget the upcoming Qt4 (and Kde 4): “The combined effects of many low-level improvements already in place in Qt 4 mean that applications will have executables about 10% smaller, will start up 20% faster, and will consume about 15% less memory compared to Qt 3.” (from Trolltech’s website).
I second what mike says.
On my k6-2 450Mhz system the redraw seems really noticeable.
I upgrade my video card from a 4MB PCI Matrox Millenium to a first generation 32MB Geforce DDR. It has helped in areas where I hit the maximise button but not much with the redraw.
I haven’t tried the nvidia binaries because it is said that 2D performance is actually lower than the Xfree versions.
@Christopher X: You have a point about lower-end machines. Lower memory usage would help those out. I do feel kinda bad to be leaving them out, but at the end of the day, it comes down to limited developer resources. When a gig of PC3200 is $126 on pricewatch, can you really afford to spend the developer resources needed to cut memory usage, or would you rather improve the interface and rest easy that anybody with enough memory will still get good performance? There are still performance problems that need to be worked out, but almost universally (with notable exceptions, like KDE’s startup time) it’s a matter of smart behavior rather than fast code. There are lots of things (eg: synchronized resizing of windows) that actually make things marginally *slower*, but significantly improve the *feel* of the UI.
And a really good programmer knows how to write tight code that limits mem usage and writes to disk while using CPU time to its best benefit.
None of them happen to write code for Mozilla’s XUL, the OpenOffice toolkit, QT+ or gtk.
Its not just the toolkit but the apps themselves and X of course and a bunch of other culprits who all need to be locked in a room with no caffeine for a couple of days till they figure out how to make linux gui framework better for all involved.
That being said. I have always preferred in general gtk apps (no religion to it btw it just seemed to work out that way) and moved to gnome to keep the consistency of look and feel and to give it a try.
When Gnome 2.0 first came out I was surprised about how fast it was next to KDE on my SuSE box. Outside of Nautilus everything else felt way faster despite the redraw issues.
All I wanted was a complete set of Preference/configuration tools and a faster Nautilus. As of Gnome 2.6, I got a faster Nautilus but everything from startup on seems slower.
Ugh. Is it just me or did Gnome get slower from 2.0 to 2.6?
Why would your toolkit be writing to disk?
why does every attempt to pass off XP as fast?
win2000? yes that was fast on my machine, but redraw problems are minimal at most on gnome, now when i tried XP on the same machine, OUCH!
gtk isnt perfect, and can be faster. but come on, i will never honestly believe XP is fast at anything. ive seen it run on brand new machines 2.4 gig P4’s with a gig of ram, and waiting for every window to open is just disgusting.
win2k was basically the same in terms of speed as gnome.
i sometimes wonder if people even have their system configured properly because there is no way these redraw problems on DECENT (athalon xp 1700, 512 ram) exist.
(note, on complicated gtk lists it does slow down, but far from unbearable)
curious, what is now the application startup problem in kde.
from what I understand, the symbol lookup at runtime issue was fixed with kdeinit. does anybody know what the new problem is?
on the gnome side, application startup has become much slower. what’s happening here??
Also, does anybody know how much of the problem with gtk is due to pango?
If anybody has new thoughts/links, maybe you can post them here.
Anonymous person says:
Why would your toolkit be writing to disk?
Not saying that it does and I was not clear.
A good programmer knows that resource management does not begin and end simply with mem usage. Disk read/writes as well as cpu usage and a number of redraw and other perception issues play into the user perception of performance.
This is a general rule and not one limited to gui toolkits.
I was not clear on that and I acknowledge that fully.
What I am saying is that there are a number of factors and groups of people involved that really need to come together and work as a unit to help resolve the perception of a slow gui in most linux gui environments.
I still find KDE app startup slower than gnome app startup but your mileage may vary.
Other people insist that KDE in general is faster.
However, I do see the redraw issue as vitally important to resolve for the future of the gtk toolkit and speed in general. Honestly, I am running the default Gnome 2.0 from Sun on a little Ultra-Sparc and my perception is that it is quite snappy. It is also my perception that Gnome 2.0 with all its warts and limitations seemed to be much quicker than say Gnome 2.6 and I have no idea how much of that is a gtk-2.x issue.
Gnome truely is in a sad state. Ive been using it since the 2.2 days and must say that 2.6 has left a bitter taste in my mouth.
Gnome continues to become slower and slower, my favorite features get ripped out on every new release(damn I loved the rounded panels in 2.2), and I dont see any noticable functionality being added.
What I find very distressing is the fact that the bulk of finincial funding is being given to the Gnome project, yet the KDE team still manages to outshine them. And now with the polarization of commerical distros and hobby distros, the commerical ones are gnome-centric(RH,*JDS).If Linux is going to become domianat on the desktop, we desperatly need to see KDE prevail in the DE wars.
* – yeah I know JDS sucks but heck windows isnt that great either, and look how well its doing.
2.4.2 made me wonder if they do any testing at all. How can you miss that it cut off large chunks of buttons? Maybe there is a good excuse… “YES! It finally compiled!”
I do see the slower redraws, but they don’t bother me. I mean, I can actually see windows move over each other….who cares? It’s embarrassing until you show them searching for a file while playing an mp3, browsing the web, and exploring a windows network; then they go “woh.”
I run Xfce on a 256MB 350 PII. It runs beautifully, maybe you can try that on your 400 laptop. You’ll find Xfce to be a very full featured environment…
They keep coming up, but I’ve never seen them. Not in all my usage of Linux/GTK ever… on any system I’ve ever owned. I used to run Linux and all GTK apps on my 700mhz, 384MB RAM system and I didn’t have any slow down issues until about 10 applications were opened, and even then it was minimal. My system now is screaming fast, and I’ve never seen any issue anywhere, but even with the old one, it never seemed to be redraw issues, just the application tending to be slow. Furthermore, where do people see these issues, can someone give me an example of how to create where I may see one using a fairly common application using GTK? … GIMP, GAIM, anything common enough will do, just tell me what to do to see one, cause I’m dying to know what all the fuss is about. Until then, I’ll continue to use all GTK2 apps because I find the themes look insane amounts better and the applications seem to just be designed a heck of a lot better.
Load up gedit with a several-thousand line text file. Try to resize it. Watch how the white content area lags behind the grey window frame.
We are now on the third revision of GTK 2.4 and the Windows version is still lagging behind with a buggy GTK+ 2.2 release. Am I just not looking in the right place or has it really been so long.
If there really is none, so much for GTK being cross platform.
> Qt 4 mean that applications will have executables about 10% smaller, will start up 20% faster, and will consume about 15% less memory compared to Qt 3.”
This is where it really pays off having a complete research department developing a library full-time instead of some freelance hackers. 🙂
Well, I’ve fixed the up problem I was facing, I read the Fabulously Friendly Manual, turned on every optimisation that is available for the driver, the next result has been a very responsive. May I suggest those who are having problems, to make sure their settings are set at the optimal level.
>”YES! It finally compiled!”
I assume you were joking. If you weren’t, you are clearly a troll. GTK+ CVS is almost always kept in compilable state.
I am very excited about the new GTK+ operating system. Since GIMP is one of the most cross-platform apps out there, the GTK+ OS will surely run on nearly anything.
However, I do think the concern about resources is valid. Other operating systems, like ROX and MenuetOS, are not nearly as resource-intensive. Then again, some OSes like Websphere are worse.
I find it very pedantic that this post was moderated down. OSNews’ readers are very knowledgeable and do not need to be talked down to like this. Please do not pontificate to us as if you have the only answers.
The redraw problem when moving and resizing windows is not directly caused by GTK or KDE. The problem lies in the window manager (WM) which eats all the cpu because its tries to redraw the windows about 100 times per seconds (too many motion events). Basically, the system is spending all its time redrawing the windows borders without having a chance to draw the content (because the WM is awake and the application is asleep).
Just limit the number of resize/redraw to less than 20 per second in the WM (using a sleep() or a timer) and your system will look a lot snapier.
The problem sometimes lies in the theme itself. X11 does not have hw support for drawing gradients or for scaling textures (I think that some extensions are coming) so if your GTK or WM theme is using one of those, it will be incredibly slow: gradients and textures are resized in software EACH TIME THEY ARE USED.
YOU SHOULD AVOID THOSE THEMES AT ALL COST!!!!!
GTK+ 2.4 (at least since 2.4.1) does work on win32, see the Tor Lillqvist release or other places :
http://gladewin32.sourceforge.net/
http://severna.homeip.net/gtk-win32.html
Turn off animations
Turn off icons in the menu
Use a light theme
Turn off nautilus previews and counting items in a folder and stuff
———————————— +
speedy gnome
For me, it’s a safe bet to create cross-platform programs based on GTK+. It is the independent way of creating GUI apps. It’s not perfect. It’s not native. But it works and keeps getting improved.
Java? Get lost! 🙂
right, but still no gtk2 on osx (with native look, I mean).
java stay here for a while
Tom how do you switch off animation in GNOME?
They keep coming up, but I’ve never seen them. Not in all my usage of Linux/GTK ever… on any system I’ve ever owned.
How can you not notice it? Here’s a few examples:
1) Take a terminal window and put it over your web browser. Drag it around the screen. See the ghosts left behind? That’s slow redraws
2) Open pretty much any app using GTK/Qt or other X11 toolkit. Resize it and watch the display try to keep up with you.
3) Change virtual desktop with a few windows open and watch the apps on the desktop redraw themselves, piece by piece
I notice this on the Slackware machine I use all day, every day (Athlon-XP 1800 and ATI Radeon 9200 (DRI drivers)). It’s not a showstopper problem, but it’s annoying and it makes the Linux desktop look bad when you compare it to the super-smooth redraws of MacOS and Win2k+.
I’ve done a small amount to help speed things up (I helped rewrite the KDE image effects in MMX), but there’s a lot of work to do and just denying the problem doesn’t help
The quickest and most impressive setting is set through gconf
browse to applicationsmetacitygeneral and set reduced resources to true.
Most of the nautilus settings are handled through the nautilus preferences or gconf apps
autilus
there are also a few performance tips in the gnome admin guide
http://www.gnome.org/learn/admin-guide/latest/performance-0.html
I sincerely hope this helps you guys. I love gnome and so does my brother on his amd k6 (300mhz) with 192mb ram. We just have different levels of eyecandy
FWIW it woulnd’t be a bad idea to have a first run thingee like kde which lets you adjust effects with an easy slider.
Damn, the backslashes get stripped out,
i meant
applications > metacity > general
and
applications > nautilus
That is the most helpful post I have seen anywhere on the web.
I keep on asking this question and no one can answer me so I give up.
Thanks you just made my day, I am going to try this, because I always notice that kwin always seems to make programs seem snappy. But I love GNOME.
The windows vs. X11-toolkits redraw performance difference isn’t that hard to explain really. On X11, when you bring a window to the front, the server doesn’t know what the window should look like (no backing store), it then sends ‘expose events’ to the window, which draws its window. If this all happens within the refresh time, no problem. But with nowadays uber-slick and pretty pixmap themes, this just doesn’t happen fast enough, and you see contentlent windows (well, not entirely contentless, windows usually have a background color, or pixmap).
On windows, you don’t have this ’empty windows’ problem, because windows keeps the contents stored in memory, so it’s always available.
The solution? That’s a tough one. A caching compositing manager perhaps (see http://www.freedesktop.org/software/xserver for what a compositing manager is, if you don’t know), but this will increase memory usage even further.
Composite Extension certainly is a way of the future. Until then use simple pixmap-less no-gradient theme. If that’s not enough dump Metacity in favor of lighter WMs.
The new xserver work does look very promising. This seems a good way to optimise in the Open Source world – push the complex optimisation work down into the lower levels (the Xserver etc.), so the people at the higher levels don’t need to worry about it.
Windows does not store the contents in memory unless a window covering that window is composited (hardly ever true).
Oh really? My mistake then.. well, the rest of the comment still stands, be it a bit shakey now
my personal impression is that qt draws faster at least on decent hardware (900mhz here). overall application startup times i guess are the same as in windows. only exception might be openoffice and mozilla, but both dont use gtk or qt, so…
what bugs me a bit about gnome is that some apps seem more unresponsive in gnome than lets say in kde…
Metacity-theme-viewer provides the time required to draw 100 frames.
Here are the numbers for the themes installed on my system:
They are in milliseconds per frame (to draw the border! not the content). The column User gives the time spent by the WM alone. The column REAL the real time (user+X11) and so is the important one:
My system is an Atlon 900Mhz + Radeon 8500
THEME USER REAL
————————-
Atlanta 1.3 3.1
Metabox 1.8 3.7
Bright 1.4 3.5
CleanIce 1.5 4.3
Mist 1.3 4.4
AgingGorilla 1.9 5.3
Esco 2.1 5.5
Simple 1.4 5.7
Wasp 2.0 5.9
SphereCrystal 2.8 7.9
Crux 5.1 8.2
Lush 4.3 9.4
Sandwish 7.8 11.5
Nuvola 4.9 13.9
Amaranth 18.5 21.2
Smokey 8.0 22.0
Industrial 7.6 30.4
Gorilla 26.7 33.6
Gorilla is the slowest. That’s not really a surprise because it uses SVG graphics that are rendered off-screen first.
It’s easy to understand why some metacity themes can’t keep up. During a resize, there might be between 50 and 100 motion events per second. No way that Gorilla, Industrial and Smokey can keep up the rate.
It would be nice to see similar benchmarks for the GTK themes.
“The redraw problem when moving and resizing windows is not directly caused by GTK or KDE.”
I think you’re right. Mainly because win32 GTK apps like abiword don’t show these symptoms.
I might be an idiot but what about the separation of X11 transparency and the direct graphics. Has there been a ripout of all the graphic calls out of the Xserver to overcome the X11 translation?
>Composite Extension certainly is a way of the future. Until
>then use simple pixmap-less no-gradient theme. If that’s not
>enough dump Metacity in favor of lighter WMs.
Oh, I can’t wait for the X server to include the composite extenstion, having each xwindow(an application have lots of xwindows) use about twice as much memory as before will be nice.
>The windows vs. X11-toolkits redraw performance difference
>isn’t that hard to explain really. On X11, when you bring a
>window to the front, the server doesn’t know what the window
>should look like (no backing store), it the
Which reminds me. X has a config option for this.
Option “BackingStore” “on”
It really helps, though it seems to cause some problems with
some drivers, atleast with the “nv” driver, scrolling _backwards_ in a gnome-terminal is much slower now, that might
a very secific case though, and might be a fault of gnome-terminal/vte.
those are very interesting
>> I think you’re right. Mainly because win32 GTK apps like abiword don’t show these symptoms.
And I think you’re wrong because Abiword does not use Gtk+ on Windows.
Well that means your config is massively screwed up some where.
I run a similarly speced system, with a older gfx card, and I don’t have any of these problems. This is even if I turn on opaque window moving.
Actually I found a heavily pixmapped theme to be quite workable with little problem of redraw time.
I don’t think there’s anything wrong with my system – I’ve noticed it in everything from Mandrake, through SuSE, Gentoo and slackware, and on previous computers and graphics cards I’ve owned as well. It’s not terribly bad, just enough of a delay in redrawing to be noticeable. Whenever I’m forced to boot to Windows (yuck), I always notice how much snappier the graphics display. (Of course, everything else is so horrible, I’m not suggesting we copy Windows!)
The current ‘solution’ for the problem, as others have mentioned, is to enable backing store, although that caused me problems with screen redrawing in KDE, so I had to disable it.
It’s clearly an issue, otherwise there wouldn’t be such an effort on the part of KeithP et al to produce a faster XServer, with compositing and damage extensions. Those extensions are designed explicitly to provide a more efficient way of redrawing a screen containing many overlapping, resizing and moving windows.
If you want a fast GUI you must make sure you have a few things(most of which have already been mentioned).
1. The right graphics driver. I used nv for my nvidia card but it doesn’t even compare to the driver released by nvidia–that one is mmuuuchh faster.
2. Don’t ever use pixmap themes. Avoid svg icons and background if your machine is on the slow side. Industrial is a non-pixmap theme good one.
If you don’t have these down you shouldn’t even complain.
I wonder if Gorilla will still be slowest when Cairo is in full use.
I currently have Cairo, libsvg-cairo, and Glitz sitting on my system. Not getting any use. Any ideas on what to actually test them with?
I never said it was not a problem, I said if you are having that much of a problem with it, it is most likely something you’ve done. Atleast this is true for fbsd, not sure about linux.
BTW redraws are noticeable on windows too, just to a slightly lesser extent.
Besides the test apps included with cairo, Waimea now takes advantage of Cairo/Glitz to do its graphics rendering.
http://freedesktop.org/software/waimea
Damn, nice! I emerged waimea followed by:
Killall metacity; waimea &
And it was running, won´t survive a reboot yet and is there an app to register with gnome to configure this thing?
The first thing I did notice though is that even with just the WM running on Cairo/Glitz the redraw issues are far less noticable. That makes the earlier remarks that it´s actually the WM causing much of the redraw issues even more plausible.
Anyway if I manage to get it to run as the standard WM under Gnome and find a capplet for it (or as soon as that becomes available) I´m switching. Can hardly wait to see GTK switch to Cairo, what an eye opener.
Anyway if I manage to get it to run as the standard WM under Gnome and find a capplet for it (or as soon as that becomes available) I´m switching.
You can save the current window manager you’re using as default saving the current gnome-session properties. Dig on the control center or use the command gnome-session-save.
“I still find KDE app startup slower than gnome app startup but your mileage may vary.”
I think it depends on your environmnet, if you run KDE kde apps starts fast as all the stuff needed by the app already is running. I guess that similar things could be said about Gnome apps in KDE.
Your idea is a common misconception. The network transparency has very little effect on X11 performance. X11 itself, in terms of raw drawing performance, is actually really fast (compared to GDI, anyway). Network transparency isn’t a big deal because the drawing commands are batched. The separation between client and server does make things more complicated, but not necessarily slower. You just have to be more careful to avoid things like round-trip calls to the server, which can’t be done asynchronously.
Well for one, I don’t have GEdit, thus the 1000 line GEdit test is out of the question, furthermore, I’d never use GEdit for a 1000 line file. If it was source, it deserves to be done in a much better editor with more towards source, and if it’s not source and is a report/essay/whatever, it deserves to be done in OpenOffice or possibly TeX (which once again may have you using a source editor).
On the other issues brought up. For one, neither my browser or terminal use GTK, so I doubt that would show me GTK redraw problems. For the heck of it I tried it anyway and saw absolutely nothing. I resize GTK apps all the time, for example, Sylpheed GTK2, which has a fairly large number of widgets and depending on my inbox can have some fair amount of information… the redraw I see doing this is negligable. As far as changing desktops with lots of windows open, this seems to be the worst example yet, from this I see absolutely nothing that I would see as redraw issues, there’s a short pause before I actually see the next desktop, somewhere around 100 milliseconds or something insanely minute like that, but I’d assume that’s FVWM’s doing.