>In my opinion, rich quality output and smooth rendering
> (via OpenGL someday) are more noble aspirations than speed.
Yes, but UNTIL that day comes (as you also said: it’s a long way off), we will have to suck up Cairo and its newfound slowness on GTK+, a marriage that makes performance even worse than it is today. That’s poor handling of the existing userbase IMHO.
I agree with you completely. But if you actually read the thread about GTK performance with cairo on desktop-devel-list, you’ll see that Owen Taylor believes that after a few optimizations of the text view, cairo software rendering will be just as fast if not faster than current rendering.
Do you have a better suggestion? How would you rather the GTK+ team handled it? It’s pointless whinning about slowness even before the damn toolkit is released. Almost all the people yelling fast/slow haven’t even used or tested it yet. Sheesh!
Well the main issue with GTK+ is that it’s basically a bloated eye-candy wrapper. Even the simpliest operation takes forever because of the eye-candy features (read themes).
And GTK+ of course isnt all to blame: X can be blamed as well. The client-server architecture of X isn’t well suited for eye-candy stuff (well for the moment). There’s so much overhead involved when you start wrapping X basic functions and it’s even worst if you try to plug too much things on top of it.
Anyway, I think X should have been replaced 5 years ago already. X is so based on the client-server architecture that 0.001% of the people use. Why would you base something on something not used at all? It would be much smarter to make the client-server aproach as a feature.
I still don’t get why people aren’t moving away from X. It’s actually one of the reasons why people slowly move to linux: there’s really no good reasons to use linux for desktop usage unless you’re a developer relying on many gnu tools/open source libs.
It’s time to move on. The whole frame buffer idea was great but it was never extended. Why? I think that the kernel should responsible of dealing with the video output (not only text-based output) in most cases anyway. That would be a smart choice since most linux users switched from terminal to gui env. already. And starting from there, a good and reliable windowing system could be made on top of it. It would be even as portable as the linux kernel. that wouldn’t be awesome?
> I still don’t get why people aren’t moving away from X.
Software compatibility. Legacy and the fear of losing their customers/users is what keeps most platforms from innovating. Then again, these customers/users are right to demand backwards compatibility. It’s a double edge sword.
But alas, I awaited the X is slow ignorant drivel, and it didn’t fail to show itself. I’d like to present some questions to our knowlegable, informed and experience critic.
1). Why is the X’ client-server architecture ill suited for eye candy?
2). What should be used instead and why?
3). What is the large overhead incurred in wrapping X primitive functions?
4). Have you measured the punitive performance damage? If so, kindly present your results.
5). What about X’ client-server architecture stinks, why does it stink?
I eagerly await your response, because so far, your points are enshrined in unfounded speculations, blatant falsehoods and just plain ignorance.
It’s simple. We’re locked into X because we all use closed source video drivers. An alternative cannot gain enough momentum without support from nvidia or ati.
No, X won’t be abandoned, at least in the next decade. It’s one of the best graphic systems with network transparency around, and if you are on a single machine there is no IPC overhead to blame (local sockets, shared memory).
Really, if there is something wrong with X it can be fixed without reinventing the wheel. Hell, it’s being constantly improved since the early 80s.
Now, the lack of proper X drivers for things like compositing is another issue that should be fixed by hardware manufacturers.
Ok just to make it clear straight away, I am biased against eye candy.
The function of a display toolkit is to provide a common interface to GUI applications. I certainly don’t care about eye candy, but speed is very much important to me.
If eye candy is to be implemented, this can be done through themes like it is done in QT, or in GTK+1, or in FLTK.
Maybe many people can’t do without anti aliased fonts, sharper images and whatnot, but there are others (of course including yours truly) who can, and what is important for them is simplicity, speed, and not getting in the way of the user. If speed is sacrificed in the main toolkit (gtk is probably the most common toolkit used by modern applications), then it spoils the main essence of FOSS, which is choice.
And incidentally, speed doesn’t just matter to geeks, so many non-geek’s I know who have tried linux complain that it is slower than even windows XP. This has nothing to do with linux of course, simply the bloating up GTK+/Gnome.
Apparently, speed is not everything because even systems with slower, more bloated, more eye candy features, like OS X’ Aqua, do not deter its users from diefying it.
Secondly, removing functionalities like internationalization, anti-aliasing, rendering and layout quality, portability, “bindability”, accessibility to cater for your so-called speed inclinations is a regression to the progress and development of software and the user experience.
If you really, crave for speed, then use GTK-1* and prior GNOME-1 releases, I’m sure there are tarball releases around.
Finally, it’s only on osnews that I here people clamoring about the slowness of X, the slowness of GTK+, the slowness of GNOME, the slowness of Linux etc. Yet none of them have provided any direct proof supporting their wild statements. All we get is circumstantial and anecdotal evidence. But how does that help the GTK developers?
Osnews has done a great job propagating the X/GTK/GNOME is slow myth that it has become the geek mantra over here and it’s slowly migrating to /.
Finally, it’s only on osnews that I here people clamoring about the slowness of X, the slowness of GTK+, the slowness of GNOME, the slowness of Linux etc. Yet none of them have provided any direct proof supporting their wild statements. All we get is circumstantial and anecdotal evidence.
Well, there is another anecdotal evidence:
Two years ago I finally throw out my P166(non-mmx) box. My new AMD AthlonXP 3200+ is nearly 2 point faster. And simple GTK tasks (menu appearing, hilighting under mouse pointer) definitely not 100 times faster. Sometime (rare)I feel it slower.
Tested on FC1 – FC3, all themes ( include simple). You need numbers ? How i can provide, may be make video and measure inter frame delay and reckognize exact time when menu item hilight and my arm move mouse ? Sorry it is must be done by developers. I just did not have camera.
I thing this is mostly because of unpredictable VM tricks. GTK developers can not guarantee that drawing of mouse / items appear exactly next CRT screen frame sweep or some definitely ( 10 frame sweep). So we get a human who try to move mouse /click it and absolutely unpredictable desktop that have huge CPU/VIDEO power. Mouse driven graphics desktop is a real time application. But X and GTK writen like it just block device that make big benchmark numbers without respect to real-time.
“If speed is sacrificed in the main toolkit (gtk is probably the most common toolkit used by modern applications), then it spoils the main essence of FOSS, which is choice.”
OTOH, If eye-candy is sacrificed in the main toolkit (gtk is probably the most common toolkit used by modern applications), then it spoils the main essence of FOSS, which is choice.
“Two years ago I finally throw out my P166(non-mmx) box. My new AMD is nearly 2 point faster. And simple GTK tasks (menu appearing, hilighting under mouse pointer) definitely not 100 times faster. Sometime (rare)I feel it slower.”
You should consider throwing out your new AMD AthlonXP 3200+ and recover your P166(non-mmx) box. Seriously.
Heh Mac OS X comes bundled with pretty fast (apple) hardware, and to be sure, I doubt you would really notice any speed lags while using it out of the box. Obviously you can throw money (hardware) at stuff to make it run fast, but not all of us have that “power” 😐
Now maybe I gave the wrong impression. Speed is important to me, but portability and internalisation are even more essential than speed. But rarely do these cause a loss of speed, don’t you think? Its just eye-candy I see no point in. That, according to me, should be the optional feature of a software.
And yes, I do use GTK+1 software if I can’t find FLTK equivalents. But take current versions of X-Chat, Pan, GAIM etc. They all use GTK+2 and AFAIK do not have the option of compiling with gtk1 support instead. Kind of negates many choices in GUI applications.
And lastly, well I have been visiting OSNews only for a week or so, but GTK+ speed issues are raised in many places.
Finally, it’s only on osnews that I here people clamoring about the slowness of X, the slowness of GTK+, the slowness of GNOME, the slowness of Linux etc. Yet none of them have provided any direct proof supporting their wild statements. All we get is circumstantial and anecdotal evidence. But how does that help the GTK developers?
How can you provide direct proofs when GTK+ feels slow? It might be fast in benchmarks, but it feels slow for users. Like on redraws, resizes, feedback, etc. To my experience with GNOME 2.2->2.10 with Gentoo and Ubuntu, nothing feels snappy. That said, since GTK applications exhibit the same issue on Windows, I don’t think it’s related to X or GNOME.
OTOH, If eye-candy is sacrificed in the main toolkit (gtk is probably the most common toolkit used by modern applications), then it spoils the main essence of FOSS, which is choice.
True, but there is room for both. The basic toolkit ships with no eye candy, but you have themes to make it look good.
Finally, you give details as to which behavior, widget, or action is slow. For example, you could state that text rendering in GTK+’s Viewport widget is 200% slower in GTK-X.X than it is in GTK-Y.Y, when scrolling 10000 lines of Cyrillic characters.
Doesn’t that make a lot more sense than “GTK is SLOW?”
source code is available, feel free to optimize it instead of bitching.
Ok, straw poll. How many C devs want to spend the next 6 months of their free time getting familiar with, and optimising, the 30 or 40 packages that ship with the GNOME desktop?
We aren’t talking about ‘Hello World’ you know. Availability of the source code is totally irrelevant. The vast majority of GNOME users don’t know enough C to be useful. The ones that do (Or are capable of getting up to speed quickly) are likely to be working on their own projects. Finally any devs that WANT to work on it have to plough through a few thousand lines of poorly documented code to understand where /whythe bottlenecks exist (No, profiling is not panacea).
I’ve always found it amazing that just because the source is available and there are plenty of users people expect extra programmers to appear like magic.
<p>Ok, straw poll. How many C devs want to spend the next 6 months of their free time getting familiar with, and optimising, the 30 or 40 packages that ship with the GNOME desktop?
<p>Pay them. Because it is free as in freedom doesn’t mean it is free as in beer. If you want to want performance improvements then pay some experienced programmers to do it or stop moaning because people spend their free time doing things they like, not things that you want.
“You should consider throwing out your new AMD AthlonXP 3200+ and recover your P166(non-mmx) box. Seriously.”
That’s probably overkill, don’t you thin. But he should consider installing the exact same software on his new box. Then he’ll get the speed increase he wants.
What I care about is, is it any faster than the previous versions?
Or more simply, will GTK ever be as fast as toolkits like qt/fltk/gtk1?
Define faster.
@chip_0: Just use some better theme, and your GTK+ will be lightning fast.
Yes, with Cairo Gtk will be fas… oh wait…
Currently I really doubt that – as painfully slow as Cairo currently is.
take your hand out of your mouth and finish your sentence already.
GTK+’s primary advantage using Cairo are richer rendering (scalable fonts and
graphics, resolution independence, etc) and higher quality output
(e.g. fonts, images, printing, etc). Cairo’s ability to use OpenGL, however,
might bring about performance benefits as well as useful visual feedback via
well designed animations. I believe that’s still a long way off.
In my opinion, rich quality output and smooth rendering (via OpenGL someday) are
more noble aspirations than speed. But since this is a geek forum, undoubtedly,
I’ll be crucified for such blasphemy. I’ll choose quality and smooth rendering
any day over this proverbial speed you geeks harp about.
>In my opinion, rich quality output and smooth rendering
> (via OpenGL someday) are more noble aspirations than speed.
Yes, but UNTIL that day comes (as you also said: it’s a long way off), we will have to suck up Cairo and its newfound slowness on GTK+, a marriage that makes performance even worse than it is today. That’s poor handling of the existing userbase IMHO.
I agree with you completely. But if you actually read the thread about GTK performance with cairo on desktop-devel-list, you’ll see that Owen Taylor believes that after a few optimizations of the text view, cairo software rendering will be just as fast if not faster than current rendering.
Do you have a better suggestion? How would you rather the GTK+ team handled it? It’s pointless whinning about slowness even before the damn toolkit is released. Almost all the people yelling fast/slow haven’t even used or tested it yet. Sheesh!
I really would like to know what you people are talking about when you say ‘slow’.
All GNOME/GTK apps in my Ubuntu are fast, kinda faster than any KDE/Qt apps in my SUSE.
Or you are running a stone age computer or you are implementing a real time 3D game with toolkit widgets or maybe it is simply bullshit.
Wich theme is fastest?
Well the main issue with GTK+ is that it’s basically a bloated eye-candy wrapper. Even the simpliest operation takes forever because of the eye-candy features (read themes).
And GTK+ of course isnt all to blame: X can be blamed as well. The client-server architecture of X isn’t well suited for eye-candy stuff (well for the moment). There’s so much overhead involved when you start wrapping X basic functions and it’s even worst if you try to plug too much things on top of it.
Anyway, I think X should have been replaced 5 years ago already. X is so based on the client-server architecture that 0.001% of the people use. Why would you base something on something not used at all? It would be much smarter to make the client-server aproach as a feature.
I still don’t get why people aren’t moving away from X. It’s actually one of the reasons why people slowly move to linux: there’s really no good reasons to use linux for desktop usage unless you’re a developer relying on many gnu tools/open source libs.
It’s time to move on. The whole frame buffer idea was great but it was never extended. Why? I think that the kernel should responsible of dealing with the video output (not only text-based output) in most cases anyway. That would be a smart choice since most linux users switched from terminal to gui env. already. And starting from there, a good and reliable windowing system could be made on top of it. It would be even as portable as the linux kernel. that wouldn’t be awesome?
> I still don’t get why people aren’t moving away from X.
Software compatibility. Legacy and the fear of losing their customers/users is what keeps most platforms from innovating. Then again, these customers/users are right to demand backwards compatibility. It’s a double edge sword.
But alas, I awaited the X is slow ignorant drivel, and it didn’t fail to show itself. I’d like to present some questions to our knowlegable, informed and experience critic.
1). Why is the X’ client-server architecture ill suited for eye candy?
2). What should be used instead and why?
3). What is the large overhead incurred in wrapping X primitive functions?
4). Have you measured the punitive performance damage? If so, kindly present your results.
5). What about X’ client-server architecture stinks, why does it stink?
I eagerly await your response, because so far, your points are enshrined in unfounded speculations, blatant falsehoods and just plain ignorance.
It’s simple. We’re locked into X because we all use closed source video drivers. An alternative cannot gain enough momentum without support from nvidia or ati.
No, X won’t be abandoned, at least in the next decade. It’s one of the best graphic systems with network transparency around, and if you are on a single machine there is no IPC overhead to blame (local sockets, shared memory).
Really, if there is something wrong with X it can be fixed without reinventing the wheel. Hell, it’s being constantly improved since the early 80s.
Now, the lack of proper X drivers for things like compositing is another issue that should be fixed by hardware manufacturers.
Ok just to make it clear straight away, I am biased against eye candy.
The function of a display toolkit is to provide a common interface to GUI applications. I certainly don’t care about eye candy, but speed is very much important to me.
If eye candy is to be implemented, this can be done through themes like it is done in QT, or in GTK+1, or in FLTK.
Maybe many people can’t do without anti aliased fonts, sharper images and whatnot, but there are others (of course including yours truly) who can, and what is important for them is simplicity, speed, and not getting in the way of the user. If speed is sacrificed in the main toolkit (gtk is probably the most common toolkit used by modern applications), then it spoils the main essence of FOSS, which is choice.
And incidentally, speed doesn’t just matter to geeks, so many non-geek’s I know who have tried linux complain that it is slower than even windows XP. This has nothing to do with linux of course, simply the bloating up GTK+/Gnome.
Apparently, speed is not everything because even systems with slower, more bloated, more eye candy features, like OS X’ Aqua, do not deter its users from diefying it.
Secondly, removing functionalities like internationalization, anti-aliasing, rendering and layout quality, portability, “bindability”, accessibility to cater for your so-called speed inclinations is a regression to the progress and development of software and the user experience.
If you really, crave for speed, then use GTK-1* and prior GNOME-1 releases, I’m sure there are tarball releases around.
Finally, it’s only on osnews that I here people clamoring about the slowness of X, the slowness of GTK+, the slowness of GNOME, the slowness of Linux etc. Yet none of them have provided any direct proof supporting their wild statements. All we get is circumstantial and anecdotal evidence. But how does that help the GTK developers?
Osnews has done a great job propagating the X/GTK/GNOME is slow myth that it has become the geek mantra over here and it’s slowly migrating to /.
Finally, it’s only on osnews that I here people clamoring about the slowness of X, the slowness of GTK+, the slowness of GNOME, the slowness of Linux etc. Yet none of them have provided any direct proof supporting their wild statements. All we get is circumstantial and anecdotal evidence.
Well, there is another anecdotal evidence:
Two years ago I finally throw out my P166(non-mmx) box. My new AMD AthlonXP 3200+ is nearly 2 point faster. And simple GTK tasks (menu appearing, hilighting under mouse pointer) definitely not 100 times faster. Sometime (rare)I feel it slower.
Tested on FC1 – FC3, all themes ( include simple). You need numbers ? How i can provide, may be make video and measure inter frame delay and reckognize exact time when menu item hilight and my arm move mouse ? Sorry it is must be done by developers. I just did not have camera.
I thing this is mostly because of unpredictable VM tricks. GTK developers can not guarantee that drawing of mouse / items appear exactly next CRT screen frame sweep or some definitely ( 10 frame sweep). So we get a human who try to move mouse /click it and absolutely unpredictable desktop that have huge CPU/VIDEO power. Mouse driven graphics desktop is a real time application. But X and GTK writen like it just block device that make big benchmark numbers without respect to real-time.
“If speed is sacrificed in the main toolkit (gtk is probably the most common toolkit used by modern applications), then it spoils the main essence of FOSS, which is choice.”
OTOH, If eye-candy is sacrificed in the main toolkit (gtk is probably the most common toolkit used by modern applications), then it spoils the main essence of FOSS, which is choice.
“Two years ago I finally throw out my P166(non-mmx) box. My new AMD is nearly 2 point faster. And simple GTK tasks (menu appearing, hilighting under mouse pointer) definitely not 100 times faster. Sometime (rare)I feel it slower.”
You should consider throwing out your new AMD AthlonXP 3200+ and recover your P166(non-mmx) box. Seriously.
Heh Mac OS X comes bundled with pretty fast (apple) hardware, and to be sure, I doubt you would really notice any speed lags while using it out of the box. Obviously you can throw money (hardware) at stuff to make it run fast, but not all of us have that “power” 😐
Now maybe I gave the wrong impression. Speed is important to me, but portability and internalisation are even more essential than speed. But rarely do these cause a loss of speed, don’t you think? Its just eye-candy I see no point in. That, according to me, should be the optional feature of a software.
And yes, I do use GTK+1 software if I can’t find FLTK equivalents. But take current versions of X-Chat, Pan, GAIM etc. They all use GTK+2 and AFAIK do not have the option of compiling with gtk1 support instead. Kind of negates many choices in GUI applications.
And lastly, well I have been visiting OSNews only for a week or so, but GTK+ speed issues are raised in many places.
Finally, it’s only on osnews that I here people clamoring about the slowness of X, the slowness of GTK+, the slowness of GNOME, the slowness of Linux etc. Yet none of them have provided any direct proof supporting their wild statements. All we get is circumstantial and anecdotal evidence. But how does that help the GTK developers?
How can you provide direct proofs when GTK+ feels slow? It might be fast in benchmarks, but it feels slow for users. Like on redraws, resizes, feedback, etc. To my experience with GNOME 2.2->2.10 with Gentoo and Ubuntu, nothing feels snappy. That said, since GTK applications exhibit the same issue on Windows, I don’t think it’s related to X or GNOME.
OTOH, If eye-candy is sacrificed in the main toolkit (gtk is probably the most common toolkit used by modern applications), then it spoils the main essence of FOSS, which is choice.
True, but there is room for both. The basic toolkit ships with no eye candy, but you have themes to make it look good.
How can you provide direct proofs when GTK+ feels slow?
You use a profiler or benchmarking tool like gtkperf.
http://gtkperf.sourceforge.net/
Finally, you give details as to which behavior, widget, or action is slow. For example, you could state that text rendering in GTK+’s Viewport widget is 200% slower in GTK-X.X than it is in GTK-Y.Y, when scrolling 10000 lines of Cyrillic characters.
Doesn’t that make a lot more sense than “GTK is SLOW?”
source code is available, feel free to optimize it instead of bitching. u ddint pay a shit to gtk so take your whinning about speed elsewhere.
ditto
Surely a few hackers will hunt for all those ‘speed issues’ on GTK+. Pay them to do so.
source code is available, feel free to optimize it instead of bitching.
Ok, straw poll. How many C devs want to spend the next 6 months of their free time getting familiar with, and optimising, the 30 or 40 packages that ship with the GNOME desktop?
We aren’t talking about ‘Hello World’ you know. Availability of the source code is totally irrelevant. The vast majority of GNOME users don’t know enough C to be useful. The ones that do (Or are capable of getting up to speed quickly) are likely to be working on their own projects. Finally any devs that WANT to work on it have to plough through a few thousand lines of poorly documented code to understand where /whythe bottlenecks exist (No, profiling is not panacea).
I’ve always found it amazing that just because the source is available and there are plenty of users people expect extra programmers to appear like magic.
<p>Ok, straw poll. How many C devs want to spend the next 6 months of their free time getting familiar with, and optimising, the 30 or 40 packages that ship with the GNOME desktop?
<p>Pay them. Because it is free as in freedom doesn’t mean it is free as in beer. If you want to want performance improvements then pay some experienced programmers to do it or stop moaning because people spend their free time doing things they like, not things that you want.
“You should consider throwing out your new AMD AthlonXP 3200+ and recover your P166(non-mmx) box. Seriously.”
That’s probably overkill, don’t you thin. But he should consider installing the exact same software on his new box. Then he’ll get the speed increase he wants.
do something or stop bitching is the theme
people should stop bitching about something if they dontwant to do something about it.