CinePaint is taking a new direction to migrate away from GTK+ to FLTK and this has lit up a new discussion about GTK+ 2.x’s speed problems on both Windows and Unix. The CinePaint project cited other reasons as well, like the non-elegance of the API, the bloated source that makes it difficult to debug it and thread-safe reasons.
Issue of GTK+’s Performance Once More in the Spotlight
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
In my opinion, those are unsound and flimsy reasons to ditch GTK+.
1). They don’t like to code in C. (Subjective preference.)
2). GTK+ is not fast and light. (No evidence provided. GIMP, Abiword, Gnumeric, and many other large apps are coded in GTK+ and they don’t seem to be slow. Weight of the toolkit has zilch to do with the application.)
3).GTK+ has threading issues in Windows Applications. (The only valid point.)
In summary, the developers don’t like GTK+ because they don’t like C. The developers feel Cinepaint will be slow and heavy when written in GTK+, without providing any evidence.
I wish them the best of luck with FLTK. I’m sure the porting to FLTK will be more of a pain than a blessing.
/me watches as they painfully rewrite the GLIB/GDK/pixbuf functionalities in GTK+.
Sounds like Qt would be a perfect fit. But Qt is not mentioned. Because of the run-time license?
No, because Qt is also big and because it seems that it is not as easy to wrap GTK around Qt as easy as it is for FLTK.
2). GTK+ is not fast and light. (No evidence provided. GIMP, Abiword, Gnumeric, and many other large apps are coded in GTK+ and they don’t seem to be slow. Weight of the toolkit has zilch to do with the application.)
I agree, there’s no evidence of GTK+ is being slow. Those apps and Pan are very fast at the startup and do anything, beside the resize/redraw. It’s just depend on how you write it.
1) Its a subjective preference, but they are the ones having to live with the code, so their preferences matter.
2) GTK+ is slow any way you slice it. Compare Abiword to KWord. On my machine, with GTK 2.4, AbiWord’s resizing is very laggy, while KWord’s is butter-smooth. Or compare GEdit to Kate. The difference is even more blatent.
It should be noted that the weight of the toolkit has *tons* to do with the display performance of the application. First, all Expose and ConfigureNotify handling is done through the toolkit and all drawing is processed by the toolkit. If the toolkit lags in handling these things, the display performance of the app will lag. Second, most apps are compositions of built-in widgets. The display performance of such apps is entirely a function of the display performance of those widgets.
Another thing to note: I’ve had cause to dig into both the Qt and GTK+ expose-handling code over the last month or two, and I can say that the two toolkits take significantly different approaches to how they handle redraw. The two approaches could be fully equivilent from a performance perspective, but if people are perceiving issues with GTK+’s speed, that’s a possible cause.
there is an old news, after gnomemeeting 1.0.2 released, the developer want to port gnomemeeting to QT for it 2.0 branch develop
See, I think we’ve got different priorities when it comes to speed. I don’t care so much about application startup (possibly because its slow in KDE and I’ve just gotten used to it). I find Pan to exhibit the characteristic performance flaws of GTK+ apps: slow expose and slow resize. To see the problem, open up Pan (full-screen), then open up its preferences dialog. Slowly resize the preferences dialog over the main Pan window. Not only does the preferences dialog lag terribly (even though it only contains built-in widgets!) but it leaves streaks on the main app window behind as expose events are processed. Now, try the same thing in knode. On my machine, its perfectly smooth, and there is no expose lag.
I understand that the resize/redraw issues plagueing many of the toolkits on Linux/BSD/etc have a lot to do with the resize, rotate and refresh rate module in Xfree, rather than GTK+ or QT. Some projects on freedesktop.org have partially solved the issue and are currently working on better extensions. There is no excuse for code written by inexperienced developers however.
That’s an April Fool’s joke
What resize, rotate, and refresh module? You mean XRandR? XRandR has no impact on performance, unless you change into an unaccelerated mode.
See, I think we’ve got different priorities when it comes to speed.
Yep, we do…. 🙂
I don’t care so much about application startup (possibly because its slow in KDE and I’ve just gotten used to it).
I don’t care about the resize. How often do you resize? I almost never resize anything, unless I have to when the lack UI design doesn’t fit the screen or so. Oh yeah, I normal do the resize when I run app at the very first time from the installtion, but after the first time I don’t need to resize it again. The startup and others are use a lot more often than resize.
I find Pan to exhibit the characteristic performance flaws of GTK+ apps: slow expose and slow resize. To see the problem, open up Pan (full-screen), then open up its preferences dialog. Slowly resize the preferences dialog over the main Pan window.
Maybe my English isn’t clear enough. I said, “Those apps and Pan are very fast at the startup and do anything, beside the resize/redraw.” I was trying to tell that the resize/redraw is too slow in GTK, which of course I agree with what everybody has said. 🙂
Show me a thread-safe toolkit that does not have problems with threading on windows.
I wish them luck, they need it.
Btw: The resize/redraw issue only plague GTK+ and VCL. Qt handles redraw/resize quite excellently.
How often do you resize?
Quite often, actually. I’ve got a small LCD. What bugs me about resize/redraw issues is two-fold:
1) It gives a very bad first impression of the program. Often, new users like to test the UI by playing with windows to see how fast they respond. When they see how GTK+ apps respond, they get the idea that “Linux is slow” or “X is slow.”
2) UI speed is all about perception. Slow resizes/redraws vastly impact the perception of speed. They give the impression that the computer is struggling to keep up with the user, which has negative psychological effects. Its a matter of feeling, and GTK+ just doesn’t feel very good.
Well said Rayiner. I have talked about these issues as well to Owen, and even filed a bug report a few months ago.
When you talked to Owen, what did he have to say, and the bug report, will it actually be worked upon? If these problems are so obvious, are the GTK people actually working on fixing these issues or will they work more towards making new widgets, such as the open/save dialog?
Any idea?
1) Its a subjective preference, but they are the ones having to live with the code, so their preferences matter.
That’s very true. But I believe there are better alternatives to the decision they’ve opted for. Changing to a new toolkit because the previous toolkit is written in language you don’t like, when there are bindings for the language you like in that same toolkit, doesn’t seem rational to me. Like I said, the rewrite is likely going going to be arduous. But it’s their decision.
2) GTK+ is slow any way you slice it. Compare Abiword to KWord. On my machine, with GTK 2.4, AbiWord’s resizing is very laggy, while KWord’s is butter-smooth. Or compare GEdit to Kate. The difference is even more blatent.
Slow? Slow, as in unusably slow? Slow as in not responsive? Slow as the application itself takes forever to load? Slow as in the application itself is slow? Slow as in what?
Unfortunately, I just got a new hard drive and I don’t have KDE installed on it yet. However, I have Gaim and Abiword, on GNOME, Windows and Mac OS X. I don’t experience these resize issues you talk about on either of these platforms. I’ll provide specs to my machine at the footnote. Gedit resizes silky smooth on GNOME too. So does Nautilus and many other GTK+ apps I use, well except Epiphany. I’d have to install KDE to see if I can notice any difference between QT and GTK+ speed.
In the past, I haven’t noticed any differences as to suggest a toolkit problem. I attribute slowness of GUI issues on a per application basis, not per toolkit bases. E.g. as a developer elsewhere sited using gtk_widget_queue_draw instead of gtk_widget_queue_draw_area to reduce redraws when appropriate and little hindrances as such.
It should be noted that the weight of the toolkit has *tons* to do with the display performance of the application. First, all Expose and ConfigureNotify handling is done through the toolkit and all drawing is processed by the toolkit. If the toolkit lags in handling these things, the display performance of the app will lag. Second, most apps are compositions of built-in widgets. The display performance of such apps is entirely a function of the display performance of those widgets.
Yes, but what does any of these have to do with whether GTK+ is 100MB large or 16MB large? If Cinepaint is target as an embedded application, it’s understandable, but outside that, its baseless. QT, Aqua, .NET Winforms are as heavy as GTK+, what does that have to do with speed of Cinepaint or GTK+?
Windows XP/Linux 2.6.4 Specs(GNOME-2.6)
1.4GHz Athlon
256MB RAM
onboard 8MB VIA Prosavage GPU
7200RPM 80GB Hard disk.
iMac
800Mhz PPC G4
512MB of RAM
60GB Hard disk space
As you can see these aren’t Rigs by any means, yet I don’t experiences this slowness you seem to attribute to GTK+.
>what did he have to say
That’s a long story and it involves other people’s bug reports and email messages in the lists. He didn’t say anything concrete, he doesn’t believe that GTK is slow (*or* that it just gives the *impression* of being slow)
> will it actually be worked upon?
From what I know, no one is working on optimizing GTK.
Everything what you have said are good point.
Its a matter of feeling, and GTK+ just doesn’t feel very good.
Depend on people… 🙂 Using QT just doesn’t feel right and very good for me. Reason:
1) It doesn’t render font same as Pango, because Pango simple made the font too beautiful.
2) The default icons, menu and etc aren’t right and messy. For the best example like GTK has the very clean icons, menu and etc.
3) Most QT apps usually feel more heavy than GTK apps for some reason.
I just checked my bug report and Owen has changed the subject since then from: “GTK+ 2.x speed problem” to “Do predictive exposes for override redirect windows.”, which means that he understands what the problem is, so that is a good first step having Owen acknowledging that things can get better.
Your windows/linux machine is basically right about that threshold where you can see the resize/expose issues. Step down to about an 800 mhz machine and you’ll probably start seeing it. I’ve got a p4 3.2 ghz now, so I don’t see it, but it was totally noticeable on a p3-600 that I had used. Qt doesn’t seem to have the resize/expose problems on lower-end machines that I’ve used.
In the long run this probably isn’t a big deal. Machines speed will probably outgrow this and as Eugenia stated in her above post they’re at least acknowledging the issue now. There was a big flame-fest last week on #Gnome on gimp.net about this issue with a lot of people saying there was a problem and Murray Cumming who heads up the gtkmm port saying it wasn’t an issue.
@bsdrocks: Points 2 and 3 are well-taken, but Pango’s font rendering (kerning glitches aside) should be identical to Qt’s. On my machine, they are pixel-for-pixel the same.
Try putting this in the file ~/.Xdefaults
Xft.rgba: none
Xft.hinstyle: hintslight
Change the first one from ‘none’ to ‘rgb’ if you want sub-pixel AA. Change the second to one of ‘hintfull’, ‘hintmedium’, or ‘hintslight’, until the Qt font-rendering matches your original Pango rendering. You should have a recent fontconfig and a recent freetype. Hmm, this should be an FAQ somewhere…
@Eugenia: Predictive exposes? IMHO, GTK+ tries to be way too smart about redraw. Qt has a very simple redraw model. On getting an Expose or a ConfigureNotify, it compresses all such events already in its queue, then immediately redraws each widget in the damaged region. GTK+, in contrast, does a lot of buffering, prediction, and hinting.
One of the biggest offenders in gtk+ 2.x has always been the treeview widget. I noticed in the 2.4 changelog that some optimizations have been done to it.
Thanks for tip! I don’t have any QT app install to test at the moment, but I have added your tip in my tips.txt. 🙂
What about wxwidgets ? are they better of gtk+ ? i’m looking for a gui toolkit programming… thanks for the replies.
wxWidgets uses gtk+2.x as its underlying native toolkit on linux so you’ll see the problems on it as well.
equals tutti frutti on the screen.
i still use it. but i still notice it.
kde just works, is fast, sans the tutti frutti.
Heres reason number 4
GTK2 is not fast and light. Several GTK applications report after migrating from GTK1 to GTK2 that they can’t recommend less than a 1ghz CPU. Speed really matters to us, but the size kills us. GTK is so big we can’t afford to QA it. Should we ship code that we can’t debug? If CinePaint crashes users expect us to fix it. They don’t care whether the problem is in our code or in a supporting library. FLTK is based upon about 120 source files weighing 337k. GTK2 is based upon about 340 source files weighing 7mb, plus many other libraries such as glib (125 source files weighing 2.8mb), gdk (62 source files weighing 938k), and gdk-pixbuf (62 source files weighing 1.4mb). An advantage of open source is supposed to be that you can fix problems yourself, but GTK is so big we can’t do it. If GTK1 is too big to for us to handle, then GTK2 is doubly so.
Slow? Slow, as in unusably slow? Slow as in not responsive? Slow as the application itself takes forever to load? Slow as in the application itself is slow? Slow as in what?
I already said what kind of slow. Slow as in redraw-speed slow. Some apps (Epiphany) are slow enough to be unusable, but most are just merely irritating.
Gedit resizes silky smooth on GNOME too.
Just the frame of the window, or the contents of the window too? Ie. is there a big grey area where the window contents have trouble keeping up with the window frame? I’ve got a faster machine than you, with a much faster graphics card, and gedit absolutely does not resize smoothly, not even when nothing is loaded.
When working on large files (2000+ lines), gedit moves into the realm of unusably slow. Wheras kate manages to reflow the text without hiccups, gedit cannot. There is a large grey gap between the window contents and the frame while the resize operation is happening. Worse, scrolling through text is perfectly smooth in kate (the mouse pointer stays glued to the scrollbar handle), while its laggy (mouse pointer lags behind scrollbar handle) in GEdit. That latter effect of the mouse lagging behind widget controls is also a common GTK+ performance issue. You can see it in large list views like those used in Rhythmbox.
I attribute slowness of GUI issues on a per application basis, not per toolkit bases.
While correlation does not prove causation, it does suggest it. Being GTK+-based, at least in my experience, is strongly correlated with having a slow UI. AbiWord, Gnumeric, GEdit, Nautilus, Evolution, Epiphany, Rhythmbox, Pan, etc, all have relatively slow UIs. Their Qt/KDE counterparts (KWord, KSpread, Kate, Konqueror, Kontact, JuK and KNode) have fast UIs. The thing is, apps like Gnumeric and Evolution are very mature, best-of-breed applications. I have a very hard time believing that their speed issues are due to coding problems, especially considering that these projects have significantly more developers than the corresponding KDE apps.
Yes, but what does any of these have to do with whether GTK+ is 100MB large or 16MB large?
Weight is a bad word to use here. My point is that the speed of the toolkit has a large impact on the speed of application UIs. In fact, for most UIs (ones that don’t use complex custom canvases) they have a larger impact than the application code itself. Studies on the MacOS showed that apps spent 90% of their time executing code in the MacOS ToolBox. I doubt the number is significantly different with GTK+. Indeed, the fact that Python/Qt apps have very fast UIs (with respect to redraw/resize) suggests that the speed of the toolkit itself is by far the dominant factor in determining the speed of the UI.
Your windows/linux machine is basically right about that threshold where you can see the resize/expose issues. Step down to about an 800 mhz machine and you’ll probably start seeing it. I’ve got a p4 3.2 ghz now, so I don’t see it, but it was totally noticeable on a p3-600 that I had used.
My iMac uses an 800MHz processor. I see absolutely no resize issues with Abiword on it.
Does anyone know more about this threading issue on Win32?
I’ve only found one message in a mailing list. If I understand it correctly, you will get deadlocks only when one thread tries to directly access a window that was created by another thread.
If that’s the only condition that makes problems, then this is nothing a toolkit can easily work around without huge efforts. In Win32 it is generally not safe to directly access windows of another thread (sometimes it works, sometimes it doesn’t, not always predictable). If one thread wants a window owned by another thread to do something, it has to send the owning thread a message so that that thread can then manipulate its windows.
I can see that this might be a problem for some people, but I wouldn’t consider it bad design of Windows. To use OO vocabulary: A window is a private member of a thread; it should be accessable only through public methods (like user defined messages).
Anyway, I would like to hear other’s opinions on this, especially more details on the GTK threading problem.
Is it possible for you to provide movie clips really demonstrating all these issues you’ve mentioned as well as comparing and contrasting them with their Qt counterparts? You could submit your findings as an article here at osnews.
Honestly, I just really don’t know what more to say. And I don’t want to give the impression that I am a GTK+ apologist. Also, do you experience this resize issues with GTK+ apps on other platforms?
There’s been some comment by people claiming to have fast GTK redraws. I’ve never seen GTK redraw with acceptable speed (meaning at around 30fps), using an athlon 2000+. Obviously when judging the severity of the redraw problem there is some personal habit involved – some people don’t resize frequently at all; others do. I find GTK to be sluggish at more than just resizing though; the whole (gnome) interface feels slower on the athlon 2000+ than full-fledged mozilla under windows on a much slower 600 MHz P3. This means things like response time in dropping down a drop-down box, displaying a menu; maximizing a window; alt-tabbing, etc etc etc – and these are definitely things I do very very frequently. The only thing that seems fast is actually scrolling (which really is smooth).
Plain old text-rendering is slow too; although it’s not always obvious that’s where the problem lies. However if for instance I use the terminal to perform a locate (really really common) and am not specific enough, then xterm is well neigh instant, konsole is an order of magnitude slower, and gnome-terminal is another order of magnitude slower. since konsole and gnome-terminal are anti-aliased, I could _imagine_ they’ld be slightly slower; but this is ridiculous; esp gnome-terminal.
I’ve heard that there’s some bad interaction between nvidia’s render implementation and gtk, so maybe that’s partially at fault – however, whatever the case it’s really really really annoying.
probably this is not a _technically_ good comparison, but nevertheless here goes: one of the most common tasks I perform in linux is web-browsing: under gnome generally this means a gecko-based browser. It’s simply not funny how much slower even a specifically gnome-oriented gecko version is than plain vanilla moz for windows; and more realistically I’ld prefer to use firefox under both windows and gnome which makes the comparison much much much worse.
konqueror (especially the newer versions) is _so_ _much_ _faster_!!! Konqueror may not be as good a browser as firefox in most ways; but at least I can switch tabs without waiting for redraws (also quite OK on the 600 Mhz windows machine using firefox)
Frankly I wish gnome would switch to Qt too 🙁
Then maybe I’ld consider it again (in january I last tried gnome for a few weeks).
Some people on this board complained that Qt-apps feel more heavy-weight. However I think this is partially due to a bad (default) icon set, which is easily modifiable, and bad kde (not qt!) defaults on what to put in every trivial app – such as 10 different confusing settings menu’s (I really really don’t need to change kde’s look n feel from inside kcalc do I?). Plain old qt apps such as qtconfig, or for instance the new 2.6 kernel xconfig feel snappy and don’t suffer from interface bloat.
Why all the talk about GTK2, you do know that Cinepaint
is GTK1 don’t you ?
You also know that GTK1 is practically unsupported now so the cinepaint team would have to do their own support ?
If anyone whats to know what that is like, build a debug copy of GTK1 and a small app that updates the label on a status bar after pressing a button. Then trace the program through from the button press, though GTK and GDK to the label update. Even better do this on windows or the GTK-OSX port so you have to go through the code used to fake X11.
You’ll the screaming for mercy by the end.
Dave
Ok, resize might not be an issue for you but I suggest you try this on that 800mhz Imac. Open some application where you will be able to see a treeview widget with a large list in it. Start scrolling down the list and see if there is a redraw problem. Treeview widgets are notorious for the redraw problem.
I use an old 400MHz K6, 256MB RAM with FreeBSD and I try to use GTK+ apps for everything as opposed to GTK+2. Even with font anti-aliasing turned off, GTK+2 is unbearably slow. Plus with Bluecurve as my GTK+ theme everything looks OK too. Not ultimate eye candy, but bearable for sure.
It is sort of a shame considering GNU/Linux is supposed to be the saviour of old hardware to have such a slow interface. Some people are talking about using 200MHz boxes with Mozilla and GNOME, and they’re dreaming.
I know exactly what you mean when you talk about response time for menus dropping down. It’s not a problem for me on my new machine, but I’ve definetely seen that on slower machines.
I used to do the same thing with a very old laptop with 80 meg of ram – only try to use gtk+ 1.x apps. Eventually though, everything started migrating over and I said fsck it and put win98 back on it.
Yeah, this old laptop was a 200 mhz. Forget about any kind of Gnome or KDE it was straight fluxbox and gtk+ 1.x apps. Win98 ran fine on it though.
wxWidgets don’t use GTK on Windows, but uses standard win32 functions. From what I understand, the threading issue only applies to Windows.
I think that there are versions for Linux that don’t use GTK, but I don’t know anything about them.
“non-elegance of the API, the bloated source that makes it difficult to debug it and thread-safe reasons.”
The non-elegance of the API and the bloated source can both be traced to C. Since C doesn’t support inheritance and overloading, the GTK+ developers have coded them in the toolkit. They did a good job at it, but it’s just impossible to attain the refinement of a more sophisticated language. Look at gtkmm, for example. The same toolkit, but with C++ interface. It’s a lot cleaner, and your own sources won’t become as bloated. Of course, the GTK+ sources remain, with all their nastiness hidden, but not gone. And C++ compilers tond to introduce a lot of bloat in their own right.
The last item, thread safety, could relate to the fact that GTK+ comes from UNIX-like systems, where threads are an alien concept. You can do fine without threads on any UNIX-like system I know of, but on Windows you sometimes need threads for performance. Such is life…
Win32 window threading is a problem for any toolkit on Windows. This is an entirely bogus point and I don’t see why using FLTK would fix this – in fact I suspect it wouldn’t, and they have just assumed this is a bug in GTK.
It is not a bug in GTK, unless you consider not abstracting the threading models of the underlying OS a “bug”, it is a problem with the design of their app. If they want to use multithreading with GTK or indeed any other toolkit on Windows, they need to perform all window handling logic inside the thread in which windows were created (the main thread in a GTK app).
This is true even in native Win32 toolkits like the Delphi VCL – the Delphi thread object has a Synchronize method which must be used for any code which touches the VCL/Window objects.
To be frank, I don’t know of any window toolkits that abstract this requirement on Windows, and I suspect neither does Robin. Unfortunately it sounds a bit like they don’t fully understand the implications of using threads on the Windows platform …
The other reasons seem similarly flimsy – GTKmm is “inelegant” but it doesn’t say how, GTK2 is “too big” but somehow the size of the X server or kernel doesn’t matter, GTK2 is “too slow” so the solution is not to work on optimizing GTK but port to an entirely different toolkit?!
To be frank this looks like a decision that was made first then justified later.
XFree is in my opinion the cause of everything being slow.
gtk and QT have to do a bunch of tricks to solve XFree’s weaknesses.
That’s why I’m looking forward to xcb and the X.org fork
ps: xcb is a x11 replacement.
Oh, I should note that unless they are using the global GDK lock to protect all access to GTK, accessing any GTK objects from multiple threads at once is walking on razor wire. GTK is (like nearly all widget toolkits) not thread safe. Using a global lock like that is pretty much asking for annoying deadlocks at some point.
I totally agree, that’s what I’ve been complaining so much when I tried a gtk2 distro based (say, mdk9.2 ?), everything is slower… I thought it was a gnome stuff, in fact it’s a gtk2 problem ?
Is that coming from AA ? and shall we send our old hardware (how much does a celeron 450 or a pIII 500 cost those days ?) just to get sure they don’t test their libs on some bi XEON and 2go of RAM ????
xcb is a xlib replacement. It is a api to access the X11 protocol.
The freedesktop/xorg and freedesktop/Xserver are using the X11 protocol.
Anybody tried to draw from another thread in MFC ?
You need to send message to main thread and only it
can redraw. At least in gtk you can use
gdk_threads_enter and gdk_threads_leave.
It works nice in Linux. But with Win32 windos just lock.
Another problem with Win32 and gtk – modal dialogs
just try
gtk_message_dialog_new()
dialog.run()
on win32 it will lock even in main thread.
The only thing i could do is to use
gtk_message_dialog_new()
g_signal_connect_swapped (GTK_OBJECT ( message_box), “response”,
G_CALLBACK (gtk_widget_destroy),
GTK_OBJECT ( message_box)); gtk_widget_show(message_box);
I did not yet tried gtk 2.4 on Win32. Hope itis fixed
Also had this. Gtk+2 was a pain in the ass on my cel 533. I used older software like galeon 1.2 or xchat 1.8.x to have a responsive and not sluggish UI. gtk2 apps always took several seconds to load, and if it was only aumix (gtk1 version ran fine).
Now I have an Athlon XP 1900+ and don’t feel any difference between gtk1 and 2.
I don’t like the fact of system ressources eaten up for nothing. GTK+ 1 shows very clear, how fast the successor _could_ be. Apps ported from 1 to 2 just remain kinda the same (same look and feel if you for example use ThinIce 1/2 as theme engine) but need way more processor power…
FLTK is fast indeed … for what it does. It is small not because it does very well, but because it does not use much. For example, GTK2 offers multi-linual rendering facilities using Pango and an input method infrastructure. This is something FLTK does not. It relys on the OS rendering engine and input methods.
I am not sure if FLTK can do as well as GTK can in framebuffer mode either?
Using the number of files and their sizes is not an argument. Many real programmers breakdown their code into multiple files for organization and easy debugging. Not all files are loaded for running an application and not all lines of code are compiled at compile time.
-Dino
Take a look at Eclipse, a perfect example of a complex app that crawls like a dog because GTK is such a crap toolkit. Its written in Java you say? Yes it is, but if you apply the FoxSWT plugin that replaces all rendering with the C++ Fox toolkit, the damn thing gets as fast as Windows.
I’ve had an opportunity to talk with the GTK team (Owen) before about performance problems, and he acts like he is wearing horse blinders. He isn’t interested in any performance issues since GTK “runs fine”. I think he’s just happy with the fact that GTK runs, it certainly doesn’t run fine.
You compare any Gnome desktop to a KDE desktop and tell me which one is faster, christ, its a joke comparison.
The only reason I don’t go bald thinking about this, is that eventually enough of Gnome and enough Gnome apps will get complex enough that one day the GTK team will wake up and go “Hey, we have a decent API that runs like shit, lets fix that”.
I think pango’s text rendering slows down everything. I believe a lot of work has to be done optimizing libpango.
isnt OOo switching to gtk?
His list of things is so beautiful that I will soon create an adjective in my vocabulary to give him tribute. We have Shakespearian, Orwellian, we will have Rowian
This guy is regularly badmouthing the Gimp-devel mailing list accusing the gimp-developers of almost everything (esp. Sven Neumann, who is always neutrally answering, I do not know where he can find all the patience to). He is a well known specialist of Press Releases, which most probably explains its attitude.
I am using GTK2 on a 4-years-old 600MHz machine, and I have yet to see any slowlyness of GTK! What the heck is this kind of 1 GHz requirement. Not only it is crap, but the Mr Rowe does not even take the responsability of its words.
Of course the great thing is that CinePaint is GPL, so if someone wants to continue GTK2 development they can.
Gladly. How do you make video? Do you think a webcam would work, or is there a way to capture the picture on screen?
You could try xvidcap
http://sourceforge.net/projects/xvidcap
To make movies of your desktop, try vncrec, a patched vncviewer that records the vnc session – http://www.sodan.org/~penny/vncrec/ – obviously you’ll need to be using either the Xvnc server or I guess the KDE Desktop Sharing software would work too.
This will generate a .vnc recording which can then be converted into a movie format using transcode.
Hope that helps!
I’m with you with “I have yet to see any slowlyness of GTK”. I run only GTK2 apps, and it runs perfectly.
OTOH, a week ago I reinstalled all GNOME, updating to 2.6. During this process (I was using GARNOME, and compiling everything), I tried KDE 3.2.1 that comes with Slackware CURRENT. And I saw just the oposite of what everyone is saying: KDE was damn sluggish. Konsole had the slower screen update I ever seen.
So, I think was people are forggeting is that video drivers can affect the performance of the toolkit. I’m using a GeForce2, with the latest 5536 drivers.
If you want to see how slow gtk2 truly is, put it on a pentium1. Compared to gtk1 and fltk, abiword is intolerably slow. On files larger than 2 pages or so abiword can’t render text to keep up with my writing! I usually have to wait 30 seconds or so after typing a paragraph to see what I just typed.
GTK runs fine on my 700 Celeron, my 224 Cyrix and my 350 PII. Yea, things are slower than on a quicker machine: DUH! I am not saying GTK isn’t slower than QT and others, but you people seem to think GTK is like half as fast as QT.
Someone above compared Kate and gedit. Kate is a more complicated app, but I can see the widgets show up as it loads. Gedit pops up. The Gimp runs great on a 700 celeron, and I would imagine it’s a relatively complicated application.
I think most of these application issues are as much the applications fault as the toolkits. Seems to be a trend for developers to blame toolkits and libraries and never their own code.
The one thing I find slow in GTK:
Icons in menus.
The widgets showing up as it loads is not so much a problem with the toolkit, but the fact that KDE apps in general have very long, involved startup sequences. This is an acknowledged problem with KDE. As for icons in menus, it should only be slow the first time the menu is loaded. Qt loads menu icons before displaying the menu. GTK+ loads them on-the-fly, which creates an annoying effect the first time the menu is shown.
I know of two apps.
http://www.unixuser.org/~euske/vnc2swf/
and
http://xvidcap.sourceforge.net/
Something Eugenia failed to mention is that they claim QT is just as bad, and I quote:
http://cinepaint.bigasterisk.com/WhyMigrateFromGTKToFLTK
GTK and QT are just bloated and need to be redesigned from scratch to have a good design, but the authors won’t do that and will continue giving us bloated code.
So the pretty boy of the API world (QT) is just as bloated as GTK in their opinion. Hah!
Nevermind my last comment, apparently the comment about QT being bloated is from a contributor instead of the article author. (Blasted site just runs user comments in with the article. Bleh.)
I don’t know how GTK implements threading for it’s win32 version but they could probably solve their problems by using lightweight threads instead of regular threads, these lighweight threads are called fibers wich are schedulled inside the app itself and not the kernel. Mozilla for example uses fibers instead of threads in some cases.
I think it’s fine to use gtk for menus and stuff like that, but since it’s a video editing app they sould render the video stream itself with some other lib (SDL?).
> KDE Desktop Sharing software would work too.
Forget krfb. VNC servers that poll the X server are unbearably slow. Either you use a VNC server using XDamage or xf4vnc: http://xf4vnc.sf.net/
I think people are missing the point. The biggest problem with thier of those toolkits for them is that if a bug occurs there is just way too much code to sift through.
I switched to Gnome from KDE a few months ago. I really like QT’s speed in redraw, but there seems to be a lot of flicker with text. For instance, when I would move my mouse through a menu, the text would flicker white when the mouse hovered over, then redraw as the selected item. I hope that makes sense.
I always got a sort of unprofessional feeling from KDE from all the clutter and the way the menus and configuration system were setup. This was made worse by the flicker. Note that I don’t mean traditional random pixel “noise,” I just mean that stuff would randomly refresh and I could see the refresh and it didn’t look too spectacular.
I’m in a hurry, so I’m probably not to articulate here, but although Gnome redraw and refresh is slow and needs work, I tend to work with apps in fullscreen, so I don’t notice it. I never encounter the flicker in Gnome, and the whole desktop feels more professional to me (though I hate the way it’s so loosely packaged).
I do wish GTK could redraw faster. The way Gnome looks and is designed really appeals to me, but I have to admit how bulky it feels at times.
In case you’re wondering, my system is:
2 1GHz P3 (dual)
512mb RAM
g400 video
Unfortunately, while reading their comments, some of them struck a chord with me. First of all, I like C. I also like Java and Perl and PHP and abhor C++. That said, learning to program in Glib/GObjects is a pain the arse. I’ve done some Object oriented programming using C and macros before (OOC written by some guy). It has a not-too-bad learning curve. The problem with Gnome and Gtk2 is that there aren’t enough good documentation that discuss the theory and the basics of programming with it. Everyone will refer people to the API ref which is generated from code, but it’s not enough. How does a programmer know how to do even the most basic thing? Going through the API ref to learn to program a system is like having to reverse engineer a program to understand how it works.
I am by no means novice at programming. If I really, REALLY wanted to learn Gtk2-glib programming, I could. But I just want to really learn it. I can’t spend hours analyzing people’s code.
BTW .. there ARE a few good articles on the web on GObject programming. One of them isn’t even linked from the developer.gnome.org website.
As for bloat and slowness, it’s certainly possible. Only benchmarks and subjective observation can tell for sure. Subjective observation, they’ve already given. Regardless, as a software developer, it is always good to improve ones work.
Well, why not fork the project. One fork ports it to Gtk2 and the other to whatever they want. Let them announce it on their web page that they’re looking for people to do the Gtk2 port. Perhaps they might be wrong with the decision to go FLTK. Having to version will allow them to compare. It would also lay to rest all these debates.
I think this is a good choice. FLTK is a great gui toolkit which has many benefits. “FLTK provides modern GUI functionality without the bloat and supports 3D graphics via OpenGL® and its built-in GLUT emulation.” And “FLTK is designed to be small and modular enough to be statically linked – the “hello” program is only 97k when compiled on an x86 Linux system!” It is also very cross platform (Linux/Unix, Windows, MacOSX) Not to mention that it’s easy to learn. There are other apps in the film industry which us FLTK like http://www.thirdwishsoftware.com/magpiepro.html
If the problem does stem from an overly complicated rendering logic… how difficult would it be to replace it? Or allow for different algo’s to be used?
For god´s sake, don´t use FLTK. Use Fox or another one
There is a comparation of widgets sets
http://freshmeat.net/articles/view/928/
Recent announcement posted on April 1. Does that make you suspicious about its accuracy?
No, because Qt is also big and because it seems that it is not as easy to wrap GTK around Qt as easy as it is for FLTK.
Wrap GTK around Qt. Now that really is funny! I wasn’t under the impression that they were wrapping FLTK around GTK – if they are then what’s the point?
That’s an April Fool’s joke
Yer, but it certainly didn’t look like it. It would have been a joke had GTK been better at what it does than Qt, and that really would be funny.
1) It doesn’t render font same as Pango, because Pango simple made the font too beautiful.
2) The default icons, menu and etc aren’t right and messy. For the best example like GTK has the very clean icons, menu and etc.
3) Most QT apps usually feel more heavy than GTK apps for some reason.
Congratulations on a load of bollocks. Pango certainly handles fonts quite well, but I don’t think that you can say that Qt handles fonts badly. It has had support for anti-aliasing and other font handling for ages.
Oh wow. You think the icons/menu are messy. Err, Qt doesn’t have a menu, or any default icons – they fit in on the desktop it is on. I assume you mean Qt.
Oh, and the ubiquitous “Qt apps feel heavy”. They’re not polished, they’re not clean….. I’m afraid these are not valid reasons.
I switched to Gnome from KDE a few months ago. I really like QT’s speed in redraw, but there seems to be a lot of flicker with text. For instance, when I would move my mouse through a menu, the text would flicker white when the mouse hovered over, then redraw as the selected item. I hope that makes sense.
No it doesn’t make sense because it doesn’t happen. I’ve seen one bad thing with Konqueror probably related to redrawing – a scrollbar on a web page disappears at odd times, but it is fairly rare. I’m sure there are more problems, but they are things that need to be identified and stamped out just has Microsoft has spent billions doing. Apart from that – nothing. Qt is technologically sound.
I always got a sort of unprofessional feeling from KDE from all the clutter and the way the menus and configuration system were setup.
Describing “a sort of unprofessional feel” does not describe anything at all. Besides, this has nothing to do with Qt.
I never encounter the flicker in Gnome, and the whole desktop feels more professional to me (though I hate the way it’s so loosely packaged).
We get a lot of meaningless recurring words with GTK and Gnome. “It just feels more professional”, clean, polish….
I assume you mean Qt.
Word tied! I assume you mean KDE.
No it doesn’t make sense because it doesn’t happen. I’ve seen one bad thing with Konqueror probably related to redrawing – a scrollbar on a web page disappears at odd times, but it is fairly rare. I’m sure there are more problems, but they are things that need to be identified and stamped out just has Microsoft has spent billions doing. Apart from that – nothing. Qt is technologically sound.
No, this really did happen. I didn’t switch to Gnome because I really wanted to flame KDE.
I’ll admit, this is the only QT problem I really experienced, but plenty of people have been using the criticism of GTK as a springboard for Gnome criticism, and I was replying to that.
When I click on the Kicker, and move the mouse through the menu entries, I can see the text redraw in it’s different color when the mouse is over. It goes white really fast, then jumps to the new color.
When I hover over different toolbar buttons, I can see the borders turn white really fast, and go to their new colors with the mouse over them.
That is what I was talking about. Denying that the problem exists is no way to solve it. Claiming that I’m lying simply to get brownie points for “my team” in a pseudo-flamewar is just as childish as actually doing it. I really like QT and KDE, but these redraw problems made me switch.
Describing “a sort of unprofessional feel” does not describe anything at all. Besides, this has nothing to do with Qt.
No it does not–I believe I was responding to someone else’s comment about KDE. I’m certainly not making the claim that because I have problems with QT and KDE both, all of the problems are with QT.
We get a lot of meaningless recurring words with GTK and Gnome. “It just feels more professional”, clean, polish….
They are very meaningful. Having a desktop feel professional and polished is extremely important. Granted, GTK’s slow refresh works against Gnome, but so do the flicker problems I have had with KDE. Granted, last time I used KDE was in the 3.1 days.
Actually, there is a problem with flickering in Qt in some places. The problem the original poster is specifically talking about isn’t really a flickering problem. Its a matter of the fact that most Qt themes change text from black to white when selected, and back to black when they are no longer selected. When running your mouse down the menu, that changing from black to white and back can make it appear like the menu is flickering. Most GTK+ themes don’t do this, and as a result look more solid.
Also, bsdrocks does have a point about the other things he mentions. Qt/KDE does tend to space toolbar icons too closely together, and is stingy with spacing in the toolbars and menus. For example, buttons with an attached drop-down menu (eg: back button in konqueror) have an arrow close to the icon, while GTK+ gives the arrow some space. In general, the layout of GTK+/GNOME apps is nicer, with better sizing of dialogs. For example, KDE dialogs are annoying because they often *require* resizing in order to see everything, like GNOME dialogs are usually always sized properly to begin with.
A lot of slowdowns are mostly because of bad settings.
I read above somewhere, quote: “a scrollbar on a web page disappears at odd times”.
I never had that problem, but I’m sure it could be a bug in the used theme/style.
One thing I noticed about the QT listview component (and maybe also the cause why the GTK treeview component is very slow), is that all items are drawn.
When I use a QT listview and add thousands of items, these are all drawn, even if they’re not on the screen. Well, this only seem to happen at loading the listview as resizing is fast.
Better would be to use the “virtual” approach and only draw those items that are actually on screen.
Loading or resizing a huge listview or treeview only takes microseconds instead of seconds or even minutes.
But with computers getting faster all the time, these things get overlooked.
I do not understand why you all argue about Qt, since they have already said no to it. I agree it is not mentionned on the web page of GTK1/2 bashing, but you can find it on cinepaint developers mailing list:
http://sourceforge.net/mailarchive/forum.php?thread_id=4177463&foru…
“5. There have been suggestions to adopt Qt, but that has licensing issues
that make it undesirable for a project that supports both open source and
commercial developers. Making studios buy third party software in order to
develop plug-ins for CinePaint is not in our best interests. Moreover, it
seems unfair to help get Trolltech developers paid ahead of our own
developers.”
Yes, the license is the “official” problem. The Kompany and other commercial companies are using Qt, so are doing Free Software orgonisations (KDE), but it seems that there are still people that do not like their licensing…