OSNews

first post

Be prepared to be the first to post on this release throughout the *entire* internet; I posted this news only a few minutes after the official announcement came in the email .

My understanding: When someone writes a theme engine to use it.
Other than whatever just works differently under the scenes: Which I'd imagine is quite a few small details.

"This is really nice, but when will the Cairo stuff be used by programs? Also, when this is done, canw expect GTK+'s redraw issues to go away?"

Cairo is already used by several programs like poppler which forms the basis for Evince now in GNOME 2.12. Redrawing should be much more smoother.

This is really nice, but when will the Cairo stuff be used by programs? Also, when this is done, canw expect GTK+'s redraw issues to go away?

On the contrary, it will be even much slower than it was - and it was already way much more than too slow.

This is what Richard Stellingwerff says about it:

"That’s right, I’m working on a new version of Clearlooks ... It’ll be shinier, prettier, and… oh right, slower. Right now cairo isn’t exactly “fast”. I can’t give you any numbers, but believe me… You’ll see and feel the difference. This makes sense though, considering the complexity of the drawing operations."

The GTK+ guys should really, finally, focus on performance. GTK+ has been unacceptably slow for years, and its developers were constantly ignoring the huge flood of complaints from thousands of people - whenever there was an article about GTK+ 2.x, instead of discussing the new features, people were always talking only about its slowness. So many threads about it here at osnews.com, too...

And now, instead of finally doing something about it, they make it even slower.

Uhm yeah, how smart of you to completely ignore the "With time, cairo will be optimised, and the speed issues should dissapear" part.

Unacceptably slow my ass. GTK might not be the fastest toolkit but it's acceptably fast. Just because people complain doesn't mean that it's the most important issue. People will always complain no matter what you do.

Uhm yeah, how smart of you to completely ignore the "With time, cairo will be optimised, and the speed issues should dissapear" part.

I have no reason to believe it. The GTK+ programmers have proved to be incapable of doing anything significant about the performance for years. How many times have we heard "with time, the speed problems will be fixed"? And the result - nothing.

So the recent optimizations don't count? It seems you're only interested in slandering the GTK developers. Grow up.
Pretty much the only situation in which you notice the slowness is when resizing windows. Do you resize windows all day long, non-stop? Can you wink your eye faster than GTK can draw a button? No? I thought so.

Pretty much the only situation in which you notice the slowness is when resizing windows.

Definitely not. I notice the GTK+ slowness in almost everything. Many, many things. For example - opening a context menu with a right click is not only noticeably slower than in other toolkits, but it eats 10 times more CPU cycles. The same with switching tabs - again, noticeably and sometimes even dusturbingly slow (on the Windows version if GTK+ 2.6, I can even see it slowly drawing the individual widgets in the tabs, one by one - on a 2.4 GHz CPU!). The TreeView, that's often totally hopeless... The new open/save dialog is, again, much slower than for example the Qt open/save dialog (noticeable delay loading any directory, no matter how short it is). And of course the most famous problem - drawing speed generally. You'll notice it in any graphics app, but in many others as well. And redrawing, when you drag windows around etc. Etc. etc.

Can you give some more information about your hardware?

I'm unable to duplicate any of these complaints on my 2.8GHz CPU. I get split second response on all the operations. Unless your system is swapping constantly, none of these should take more than a second.

Well, I am a fan of Gnome. And to be honest, I really don't see much of a speed problem on my hardware, but it is obviously a concern for others judging from the general complaints I've reading for years.

I don't pay close attention, but I do recall a GTK developer being asked about the speed problem during an interview in the not so awfully distant past, and his response was basically, "What speed problem? I don't know of any speed problem".

I found that response to be disappointing. Not because I have a problem with the speed, personally. But because GTK does have a reputation for slowness among users and the developer seemed so totally oblivious to their concerns.

ldouglas - I totally agree with you. I'm not as much disappointed with the performance problems as I am with the GTK+ developers' attitude for all those years. That they constantly refuse even the slightest possibility that there could be something wrong with the peformance in some single, particual aspect, no matter what thousands of users are constantly saying. That they still keep saying it's fine and are not interested in doing anything about it, despite numerous requests to do so. I've even seen a discussion where a GTK+ developer repeatedly refused patches for better Pango performance - again it looked like he was still refusing even thinking about the possibility that performance improvements could be a good thing. This is really discouraging.

And yet, with all that searching, you couldn't bothered finding the follow up messages.

The GTK maintainers want a complete solution, not nasty little hacks here and there to work around, possibly, architecture flaws - they're developers not Microsoft PR men dressed up as programmers; they want to see a solution that actually solves the problems for the long run rather than providing instant gratification for the small few in the cheap seats.

Cairo is providing that solution, it also provides a solution for the number of other problems that GNOME and GTK are facing - maybe if you took the time to research about their future plans and where they're looking at heading, then maybe you wouldn't make such ignorant statements.

Owen Taylor probably has to delete a dozen vague complaints about the performance of GTK+ from his mailbox every hour. Every time he offers to answer questions about GTK+, hordes of people pop out and complain about the speed of the toolkit without providing specific details. The way things work is that people get tired of listening to vague complaints about the performance, especially when they're never backed up by profiling figures or even the slightest hint of someone getting off of his indignant duff and doing some of the work.

So in your roundabout way of maligning the developers of the toolkit through characterizing their position as one of pure denial, you fail to characterize what actually transpires. If you have demonstratably improved the performance of the toolkit in some manner without creating regressions and have had your contributions, would you please be so kind as to give us those details? That would be much better.

Hello? How the hell do you expect developers to fix your problem if they can't even reproduce it themselves?!

Actually, when the layout is complex and the EXPOSE handling gets backed up, yes I can wink my eye faster than GTK can draw a button. Well, on my laptop, anyway...

Oh, and gnome-terminal deserves a special place in hell. SBCL's "compiling from source" page actually singles out gnome-terminal and OS X's terminal, pointing out that you shouldn't try to compile SBCL from those programs because they're slow handling of the compiler's output will dramatically increase your compile time.

screen
make
#click close window
#wait an hour
screen -r

:)

> So the recent optimizations don't count?

I haven't noticed any speed improvements so NO, they don't count. Not to me and not to anyone else who hasn't noticed.

> Do you resize windows all day long, non-stop?

Of cource not but when I do resize, I get really annoyed.

> Can you wink your eye faster than GTK can draw a button?

Yes I can, maybe not buttons specifically because they are small and quickly rendered but there are lot's of other stuff that renders slow enough for me to have have time to wink, and that's exactly the problem. I don't know what it is that hampers performance of GTK2, but I do know this - It's bad enough to drag down a whole desktop based on QT. Here's a small demonstration you can do yourself:

1) Start KDE. Launch a KDE application and click on the taskbar so the application is minimized, do it again so it gets maximized. Instantaneous right? No flickering.

2) Stay in KDE. Launch a GTK2 application and keep it visible. Now launch a KDE application and do the minimize/maximize thing with with the KDE app. Notice anything strange? Flickering - very similar to what you'll see in Gnome. All you need is to have a GTK2 application *visible* and QT applications will exhibit the same rendering problems that plague Gnome (and this effectively kills the nice, snappy "feel" of KDE). Because of this, I never use GTK2 applications unless I can't find a reasonable QT replacement.

Now, you say there aren't rendering problem with GTK2? Are you really, really sure about that? The reason I ask is because GTK1 doesn't cause the minimize/maximize problem, Motif doesn't do it either and QT sure as hell doesn't. I realize it may seem trivial to most people but when it comes to desktops it's all about "feel" and if rendering is fast it'll give you the impression of robustness.

Which Gtk2 app are you referring to?

I'm using Ubuntu/GNOME and I don't see any flickering. (1) is instantaneously maximizes and using a visual "minimization animation" during minimization so you know where it went. I did (2) with every GNOME app I can think of and couldn't find anything. With K3B, there's a brief flicker (.1 sec) and a slight sluggishness (barely perceptable but its there), but I doubt it annoys anyone who isn't looking to get annoyed.

Do it from KDE, of course you don't notice a difference when you're in Gnome, and that's because there's a sluggish redraw (compared to KDE) no matter what you do.

And I mean any Gtk2 app.

Dude, obviously complex Cairo themes are slower than current themes, because every widget is rendered by sophisticated vector drawing functions. This can't be compared to current pixmap-based themes or the primitive Gdk drawing functions we are using in current engines.

This approach is infinitely more powerful, but it also comes at a cost. There will always be simplistic themes for those on slower hardware or who are extremely pedantic about reaction times. Vector graphics are the future and this will allow us to have extremely nice looking widgets (for example the look of Aqua widgets could easily be recreated by just using Cairo drawing functions) which are totally _scalable_. And if your computer is fast enough to render the items at acceptable speeds (which will become more and more likely as Cairo gets optimized and accelerated), it won't have any significant impact on your system resources.

Why not do something intelligent with those vector graphics? Render them to pixmaps, and then use the pixmaps instead of re-rendering the same vector graphics over and over. When they change the size of a control, cache some more pixmaps. That way you get the speed of the pixmap themes, and the beauty of the antialiased lines.

Unfortunately, scaling is bunk. Yes, it does mean I can make it look the same at 1600x1200 as it does at 1024x768, just that it will be crisper. But when I switch from 1024x768 to 1600x1200 I want more viewable size, so I want it to shrink anyway.

Why not do something intelligent with those vector graphics? Render them to pixmaps, and then use the pixmaps instead of re-rendering the same vector graphics over and over.

That's certainly an option if it would turn out to be a lot faster, but it would also waste some memory. We'll see.


Unfortunately, scaling is bunk. Yes, it does mean I can make it look the same at 1600x1200 as it does at 1024x768, just that it will be crisper. But when I switch from 1024x768 to 1600x1200 I want more viewable size, so I want it to shrink anyway.

In a vector world you could make your interfaces take up as few space as you want, independent of your screen resolution. That's how it should be. It works for fonts, why not for the rest of the GUI?

I think it'd be possible to implement caching of renders. Cairo may already do that. But it should be rendered live at some point, not in advance; it's not that heavy a thing to do (like compiling) that you need to do it in advance for everyone.
It may turn out that you can render the svg's with a small efficiency loss: I wish I knew more about it though.

Scaling isn't bunk, you're just confused. Scaling happens with DPI, not resolution. Ergo, if you switch from 1024x768 on a 17" monitor to 1600x1200 on a 20" monitor, the sizes should remain the same, since both are around 96DPI. However, if you go to 1600x1200 on a 133dpi LCD, or 3200x2400 on a 200dpi LCD (like IBM's or Viewsonic's), you damn well want the sizes to change!

"And now, instead of finally doing something about it, they make it even slower."

Gnome may not be fast enough for you, so maybe try the fast XFCE desktop.

BTW XFCE is based on GTK+. Think what this must mean.

Correct, XFCE is much faster than Gnome. But XFCE 3.x (GTK+1) is faster than XFCE 4.x (GTK+2), and the same applies to GTK+2 and GTK+1 versions of Firefox, Mozilla, X-Chat etc. Fast software run fairly fast on GTK+2, but slow applications are really, really slow.

Correct, XFCE is much faster than Gnome. But XFCE 3.x (GTK+1) is faster than XFCE 4.x (GTK+2), and the same applies to GTK+2 and GTK+1 versions of Firefox, Mozilla, X-Chat etc. Fast software run fairly fast on GTK+2, but slow applications are really, really slow.

Uhm... pardon me, but isn't Firefox based on a language developed by Mozilla (XUL)? Or is that something else entirely? 'Cause for instance in Winbloze I don't need to have the GTK+ toolkit installed to install and use Firefox.

its up to the theme developers

Cairo can't do anything about anti-aliasing rounded window corners. Cairo is only about drawing to the window --- the window manager handles drawing the borders. To get smoothed window borders, you need a window manager drawing anti-aliased window borders (via Cairo), and an X server that supports compositing of windows to preserve the anti-aliasing effect.

Just wait until you see the candy theme we are working on in parallel. It makes Aero look shabby.

As far as I know Cairo *is* the new GDK drawing model. In other words, they'll use Cairo instead of GDK for drawing everything.

You probably forgot to compile atk

Agreed. If someone will post places in the code that need looking at, I'll definitely take a look. Maybe some smaller stuff at first, but I'll work up the skills.

“impossible to notice in practical using of Gnome”

But It is noticeable,the window area shows black for quite a short time when redrawing.

Come one man, put a screenshot, we want to see.

Ahem, we pretty much just started so it's still far from being complete, but this might give you an idea:
http://213.133.111.182/Temp/Screenshot-Calculator.png

Still very rough and the buttons look a little better by now, but that's about the style we are shooting for.

So... it looks better than Aero by looking similar to the Brushed Metal theme from Apple? I would prefer Geramik to that.

So... it looks better than Aero by looking similar to the Brushed Metal theme from Apple?

At least we are better at looking similar to Brushed Metal.
http://www.pcmag.com/slideshow_viewer/0,1205,l=&s=400&a=156757&po=3...

That kind of chrome look is very common anyway. What matters is the quality of the picture.

"At least we are better at looking similar to Brushed Metal.
http://www.pcmag.com/slideshow_viewer/0,1205,l=&s=400&a=156...

That kind of chrome look is very common anyway. What matters is the quality of the picture."

Hate to say this but the buttons in Vista looks better than in the Calculator screenshot given earlier....Though, I probably won't use that theme myself; I'll stick to Clearlooks or some lighter colors. That way my desktop doesn't seem so heavy and unfriendly.
-WereCat

Well maybe you should wait for the actual theme to be ready before you judge it to be "heavy and unfriendly". We are still mostly experimenting.

Well maybe you should wait for the actual theme to be ready before you judge it to be "heavy and unfriendly". We are still mostly experimenting.

I like the direction you are going with it.

I don't really like either of the two, but I'd probably say aspects of the Vista shot are better. The color-coded Dr. Mario titlebar in the other screenshot coupled with the "metal" look just doesn't do it for me. I like darker colors, but the split-color button faces look a bit corny.
http://213.133.111.182/Temp/Screenshot-The%20Widget%20Facto...

Plus the color selection for menus in both shots are fairly harsh contrasted with the dull gray.

Really now, I just posted the screenshot to give you an idea. Knowing us, the end result probably will be totally different anyway. This is a more recent shot:
http://213.133.111.182/Temp/Screenshot-Calculator5.png

How are the themes being made? How difficult is it to make one? I'd like to try making one soon as an experiment. Is the source available yet?

Well, again, what you're trying to copy _is not aero_. Aero was not even revealed yet by Microsoft. It will be available with the next beta or the RC series.

No, Cairo is only about drawing.

Well it's still very incomplete, so most widgets are using the default style and some might even just draw nothing. No wonder that's fast. You could probably get more meaningful results by just comparing the button benchmark times.

I've heard that Cairo will improve printing as well. Apparently whatever is rendered on the screen with Cairo will appear the same way when printed. I'm soo excited about playing with all this new stuff in Breezy!

I am running GNOME of Ubuntu 5.04 in 550 MHz Athlon with 256 MB RAM and it's fast enough. Even if KDE seems to be slicker GNOME is still fast enough and very usable with my configuration.

I have a Dell Inspiron 3700 laptop from 1999. It has a Celeron 433 MHz processor, with 256 MB of RAM. I run Ubuntu Hoary on it, and GNOME runs fine. Not blazingly fast, but much better than Windows XP on the same desktop. Even my wife likes it better than Windows, and she's anything but a geek.

this is because you use pango-1.9.1 with cairo 0.9.2

libpixman was moved inside cairo after pango-1.9.1 release and before cairo 0.9.2 release

so, it is normal. it is already fixed in pango CVS (and 1.10.0)

Baghira theme in KDE gives you a very good OSX look(brushed metal and aqua) and feel. Baghira has been there for a couple of years now. What will be better in the GTKs version of OSX theme?

Erm...it's not 'GTKs version of' an 'OSX theme'. It's a GTK theme backed by a new rendering engine.

The problem with using too much color in icons and themes, is that you always wind up with having people who don't like it, The current defaults in Gnome are sane enough, I think, althought the icons could use an update, but *not* by adding a few colors, and definitely not Gorilla or Nuvola.

Maybe Suede?

I have yet to see any icon theme for GNOME that looks as nice and polished as the current set (and this includes Suede). Currently I'm using the gperfection set, which builds on it and AFAIK many items of it are getting merged for 2.12.

An icon set needs to be complete and actively maintained, so unless Jimmac changes his style or someone else steps up and does a similar magnificiant job, I really don't think it would be smart to start from scratch with a new style. At the very least, it would have to be a serious and unquestionable improvement.

Anyway, it's quite amazing how long I've been using the current GNOME icons now and I still love them. Every once in a while I try one of the new shiny icon sets, but always get tired of them very quickly.

Anyway, it's quite amazing how long I've been using the current GNOME icons now and I still love them. Every once in a while I try one of the new shiny icon sets, but always get tired of them very quickly.

Yeah, I agree. The original icon set is the only really complete one, so I always end up using it too. It might not be as shiny as Crystal, or Apple's Aqua icons I use on my iBook, but at least it is coherent, and it doesn't pretend to be anything more than a default icon set.

"Yeah, I agree. The original icon set is the only really complete one, ..."

As far as I have seen are Bluecurve icons also very complete. Ok but their from Redhat and I don't know if they have a special copyright on it.

"...and it doesn't pretend to be anything more than a default icon set."

Yes but even the default icon set should look good because otherwise it is all on the distributers to ship their versions with better icons.

This goes in the other direction than Clearlooks which is a great theme which the distributers will adapt so that Gnome will look equal in many distributions which is better for recognition of Gnome for new users.

If they use different icon sets Gnome looks different everywhere instead having one good icon set which many distributers could use.

Hardly anyone uses a different icon set. Red Hat has Bluecurve which isn't really better and Novell uses the same style, just with some tweaks (as Jimmac works for them).

"I have yet to see any icon theme for GNOME that looks as nice and polished as the current set (and this includes Suede). Currently I'm using the gperfection set, which builds on it and AFAIK many items of it are getting merged for 2.12."

With Suede I agree with you. They look much better than the current icons because they have brighter, friendlier colors and not so many details which is better if you have small icons like 16x16.

Too many details look a little bit childish sometimes like the icon with the car for the Gnome configuration editor.

But as far I have seen the Suede icon set has no stock icons but it would be great to use the other icons of it in the next Gnome release.

"The problem with using too much color in icons and themes, is that you always wind up with having people who don't like it,..."

Yes, for me Suede is much better as I have written in an upper post but it's missing stock icons.

I think in times where we have more than 16 colors desktops can be a little bit more colorful than the default icons are. Which doesn't imply that using many colors is better.

Ok, Nuvola is maybe too colorful but Suede could be a good start for a new complete icon set. Especially it consist of SVG icons.

can I install this without fuck up my current gnome installation?(Gnome 2.10)

No.

can I install this without fuck up my current gnome installation?(Gnome 2.10)

No.

Don't talk crap. GTK maintains ABI in all 2.x releases, you can just drop 2.8 in replacing 2.6 and everything will keep working just fine.

It was a question

Yes, I only tried the Windows version on Windows XP. So I don't know if it's specific to Windows XP, but it's blatently obvious even to a person who otherwise cannot notice any performance problems with anything. Resize a window - an until you stop resizing or release the mouse button, the window contents are frozen, don't move at all. Only when you stop dragging the window border, the stuff inside the window resizes to the requested size.

And that's just resizing. The huge performance difference compared to native Windows GUI is totally obvious, too. I switch tabs from tab1 to tab2 - and see the tab2 widgets being gradually drawn, one by one. Of course it's still mostly a fraction of a second, I'm not talking about 30s delays or anything like that. But it's obvious, visible, very noticeable.

And the Windows version still has exactly the same performance problems that the X (Linux, BSD etc.) version has. Open and close a combo box in the native Windows GUI several times. The CPU meter still shows 0 percent. Just open the combo box once in GTK+ and the CPU meter jumps to several percent. The same with opening a context menu (right-clicking) etc. That's really typical - it is much more CPU-hungry than the native Windows GUI and it's often really noticeable. For example the open-save dialog - when you change a directory in the native Windows open/save dialog, it's instantaneous, absolutely no noticeable delay (must be much less than 0.1 s). With the new GTK+ open/save dialog, there's always noticeable delay (also when you just open the dialog). The redraw speed in the Windows version of GTK+ is just as bad as it is in X, possibly even worse. Drag windows with native MS Windows GUI around, and you get perfectly smooth redrawing. Move some window over a GTK+ window, and you'll see the horrible redraw lag. Windows with native MS GUI appear instantaneously, with GTK+ I can often see the contents being gradually drawn to the screen (again, it's a fraction of a second, but noticeable). And so on.

The Windows version of GTK+ simply doesn't feel like native GUI. The lack of speed is especially noticeable there, because the Microsoft Windows GUI is superfast and extremely efficient (i.e. consumes much less CPU cycles for the same tasks). If you dont believe me, just do various things with the GUI with GTK+, Qt and the Windows GUI and watch the CPU monitor. You might be surprised.

I use Windows XP with 256MB of RAM powered by a 1.4GHz Athlon XP processor. I've used Abiword, Gaim and a number of GTK+ applications on Window, and I am not experiencing any of your problems.

I do not feel GTK+ is any worse or better than Windows' native widgets or Qt. I have yet to come accross anybody who complained about GTK+ give concrete, undisputable and objective data regarding it's slowness.

The complaints have always been along the line of, "Its faster, than X but it is slower than Y." If I was a GTK+ developer and you wrote that in a bug report, I would openly insult you.

Several individuals on this thread alone have provided data that were actually systematically measured. These data showed were GTK excelled and where it had drawbacks. These are useful information developers can use to track down problems and profile.

Among the "GTK is Slow" clans, none of them have actually sat down to provide any substantial data other than, anecdotal evidence and other questionable subjective experience, not to mention geeky fetishes, like 1% spikes in CPU usage.

If GTK is really slow, I'd like the GTK is SLOW crowd to actually provide data no matter how unscientific that at least we look at study and make comparisons.

Oh, by the way, my car is better than yours and it is so blatantly obvious. Just put your car right beside mine and you will see for yourself.

If I see that GTK+ on Windows XP does not react to window resizing at all until you stop resizing the window, I absolutely don't need any scientific data to be able to say that the window resizing with GTK+ on Windows XP sucks. If I see that a feature that needs 0 % CPU in the Windows GUI needs 30 % CPU for the same task in GTK+, I don't need any scientific data to be able to say that the iplemenmtation of this task in GTK+ is inefficient. If I see (and yes, I can see it all the time, on different computers) GTK+ gradually drawing individual widgets in the window, one by one when you switch tabs, I absolutely don't need any scientific data to be able to say that switching tabs in GTK+ is substantially slower than it is elsewhere.

Is it so hard to understand? This is not some anecdotical evidence, some vague nonsense, without saying anything concrete. This is my real observation, and I've been observing this issue *very* carefully (much more carefully than most people here can imagine) and *very* often during the last couple of years. It is real. The fact that I didn't perform any scientific benchmarks is irrelevant. When the user can see that the GUI is slow, it is slow. Period.

How come I'm not seeing this resizing issues on Windows? Do you get my point now? If you see ghosts, and other people don't see them, they begin to start doubting your judgements.

In this case, people will just label you a troll, at least until we can all begin to see what you are seeing? Developers will ignore you until you provide data that is useful to them.

Throwing around inflamatory keywords like "sucks", "inefficient", etc., will only frustrate you further. It won't solve the problem, if indeed there is any.

What is it so hard to understand? What is hard to understand is that you expect developers to miraculously make GTK+ faster, without providing them with useful/concrete facts.

That's like going to the doctor and telling her you are sick but you don't know the symptoms. How is she gonna treat you?

Good point. J.M. is already in my troll list.

And herein lies the problem. It seems that anyone who reports a problem without this "scientific data" is instantly labeled a troll and discarded, ignored.

What about an end user with little or no computer experience? They see the problems, they don't know what's causing them, they don't know how to go about collecting this "scientific data", they simply report what they see and are labeled trolls for doing so and so their data is instantly disregarded. Now how is GTK+ going to improve as a result? It seem that you're happy to leave gnome/gtk to the power-users. I don't want that, I love gnome and want to see it emerge as the de facto desktop environment, but instead this level of ignorance and unwillingness drives users away. The casual computer user isn't the type of person that reads osnews, posts to bugzilla etc. They'll see the problems, get sick of them, and switch.

That situation isn't going to change unless attitudes change within the GTK+ development community.

It seems that anyone who reports a problem without this "scientific data" is instantly labeled a troll and discarded, ignored.

Exactly. There are things that people don't want to hear. It is natural - when someone likes something or even made that something, it is in the human nature to get annoyed when someone says there's some particular problem with it.

It is the equivalent of reporting bugs - normal developers are even glad when a user reports a bug. Because the developer can fix it. The developers don't ask the user "to provide scientific data & analysis". That would be ridiculous.

Again - when a user says that in toolkit XY, drag'n'drop eats 30 % CPU, while in tookit AB it's only 5 %, this particular, concrete information is enough for the XY developer to look where the problem could possibly be with this particular inefficiency. Or if they're not interested in finding the cause or don't have time for it, they say "OK, but I can't fix it,. feel free to do tit yourself". But - only if the XY developer is a normal person. In the strange GTK+ camp, user saying this thing is automatically labeled as "troll that doesn't provide any scientific data, just throwing around inflamatory keywords like 'inefficient'". This is not normal.

People have reported the symptoms! Windows take noticable time to redraw when you resize them, menus don't get populated with icons until your mouse is halfway through the third submenu, switching virtual desktops takes too long, etc.

To stretch your medical analogy a bit further: The gtk developers are a bit like doctors who refuse to even consider treating your disease (slow widget drawing) until you can give them a culture of the bacteria that you're infected with (repeatable test cases), a complete sequence of it's DNA (voluminous library profiling), and a finished, FDA-approved drug to treat it (patch that will meet with all gtk developers' approval with no further work).

How come you and J.M are the only folks witnessing these slow drawings?

Throwing around inflamatory keywords like "sucks", "inefficient", etc., will only frustrate you further.

Since when is "inefficient" an inflamatory keyword? And I actually explained in that sentence why the word "sucks" is not inflamatory there either, but a fair description. Please read the whole sentence.

What is hard to understand is that you expect developers to miraculously make GTK+ faster, without providing them with useful/concrete facts.

I already provided many concrete facts. You just automatically dismissed them. And I never said that I expect the GTK+ developers to miraculously make it faster. This is the attitude problem I was talking about earlier - you, just like the GTK+ people, have problem admitting that there could be something wrong with the toolkit you like. When people say it's slow, you say that they don't say anything concrete. When they say something concrete, you say that it doesn't matter. When you explain why it matters, you say "provide scientific data and send a patch". When people send patches, they refuse them. Until this attitude in the GTK+ camp changes, things will never change to better.

Where is the time being taken?
What functions?
What widgets were in the windows?
What containers were they packed in?
Can you provide a small test program to demo?
How about a video-screenshot?
Maybe a profiler log?

Right now, you've told us absolutely nothing, except that you see a problem nobody else seems to.

http://vektor.ca/eclipse/gtk-performance-notes.html

That's like going to the doctor and telling her you are sick but you don't know the symptoms. How is she gonna treat you?

Actually, it's more like you are telling your symptoms to a physician, but he/she dismisses you as an hypochondriac because you can't name your illness. Knowing the name and even the cure would help him/her tremedously, but that's not how daily life works.

There is no need in being so defensive. We are not getting personal with you. We are sharing our perception. GTK might be fast on benchmarks, but it still feels slow to many of us. Personally, it doesn't feel snappy on my fairly recent machines (2x XP2500+, Centrino 1.7) with four different OSes (Windows XP, Debian, Ubuntu, Gentoo). Response time is alright, but redraw is sluggish. It's mostly noticeable in XP, but I can understand it's the least of their worries.

Now, I admit my experience is not easily benchmarkable and it's fairly difficult to pinpoint the exact cause to developers. I don't have the knowledge to profile the toolkit nor have the time to learn about it. Still, does that make me a troll or a liar? Does that make my opinion completely irrelevant? I happen to be a programmer, but millions of people are not.

Last, but not the least: it's not because you can't notice it that it doesn't exist.

Everything you stated is scientific data. I think what you don't need is analist data.

Looks more like he was correcting himself. And he is the stupid one? ROFL.

I'm afraid there's no GTK+ version 2.7.x or 2.8.x available to win32 yet. The official download site for GTK and GIMP for windows is:
http://gimp-win.sourceforge.net/stable.html
The latest version available there is 2.6.8.

(someone, please, correct me if I'm wrong!)

Unfortunately the 'reduced_resources' mode is broken for ages. Turn it on, try to maximize some windows by double clicking the window bar and see what happens.
In addition, the 'reduced_resources'-mode looks awfully due to the far too thick black lines that are drawn when you resize a window.

"Also, I've run Abiword on Windows, and it's performance was great - no redraw problems or slowdowns."

Abiword on windows doesn't use GTK.