GNOME Bugzilla – Bug 135017
Performance of GTK is noticably slower than comparable widget toolkits
Last modified: 2004-12-22 21:47:04 UTC
System: Pentium 4 2.8Ghz 1GB Ram GeForce MX 440 nVidia driver XFree 4.3.0 The GTK widget toolkit is noticably slower in drawing speed on the above hardware than a comparable gui toolkit like QT, FOX or even wxWindows. Draging dialogs ontop of their parent windows in gnome causes a slight trail of gray while the underlying window repaints its damaged regions. The performance of GTK is similar to and has some of the same problems that Swing had in the 1.2 release of the JDK. An example application that exacerbates this slow redrawing speed CONSIDERABLY is Eclipse (the Java IDE). Please see the following link for the GTK2 version to download and try out: http://download2.eclipse.org/downloads/drops/R-2.1.2-200311030802/index.php The performance of Eclipse on Linux is far from anything that someone might find acceptable. Either drawing a dialog around ontop of the parent, or switching between perspectives (this is the best 'worst case' scenario), you can watch widget borders redraw and flicker into existence as their backgrounds are painted. A full switch between perspectives can take up to 0.75 seconds. While this doesn't sound huge, on Windows, or even on Linux using the SWT-Fox (swtfox.sf.net) plugin, the change is instantaneous and causes no redrawing; the middle of the screen simply switches all at once. Many people have complained about this bug in the Eclipse bug tracker to the point that it is the 2nd highest voted bug right now. Please see link here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=37683 Also note that this bug has many test cases and results from different people's system in it for you to test against or use for debugging. The biggest culprit seems to be text operations; in some cases 11x slower than the Windows result for the same benchmark. I'm hoping that we are able to uncover either deficiencies in SWT or deficiencies in GTK and work together to create a better overall user experience.
Would we like to make GTK+ faster? Of course. Is having this bug open going to help us make GTK+ faster? No. There is a Pango bug that I can't find at the moment that was opened on the subject of Pango and Eclipse and performance That has more comments there, but in brief: - The fact that Pango is slower than simplistic text layout is not in itself a bug. If Pango is fast enough to redraw all the text on the sceen at an acceptable frame-rate, than that is fast enough. If a program assumes that text layout is free and it can lay out strings many times for redraw and not worry, then that program is making an assumption about text that might work for English text, but doesn't work for more complicated languages. - Performance measurements show that for drawing, the biggest bottleneck for Pango currently is anti-aliased text drawing in the X server. So, for *drawing* (not layout) comparison to older toolkits using the not-up-to-modern-standards core X font system are not useful because it's apples and oranges. - If you want to investigate what part of Pango could be optimized to help Eclipse, small standalone *C* programs that model what Eclipse is doing are essential. (the Pango bug that I can't find has an example) Anything that requires running stuff under SWT is far too far away from Pango to be usefully profiled Feel free to file new bugs that point to particular pieces of GTK+, especially with (C) test cases, but I don't think keeping this bug open is useful.
Owen, I can understand your POV but did you even download Eclipse and run it? It's pretty much unbearable... I consider THAT a bug. Also I would have never filed this bug if the benchmarks run in the previous bug thread weren't showing a 11x slow down related to GTK... I suppose technically since things are being drawn on the screen that is not a bug, but good god, 11x slower? Not 2x as slow or 3x as slow... 11! Also keep in mind that I'm talking about running my entire desktop (Eclipse included) with AntiAliasing turned off, that is what is killing. Its not that text layout isn't free, its that its piss poor. If the developers working on Pango want a good 'worst case scenario' to test their dev releases again, we'll here it is. BUT, you guys are the GTK developers if you really feel this is a waste of time, then yes I suppose close the bug and we'll part paths here. Sorry for the trouble.
Are other GTK+ apps unusuably slow? If not, then the fact that Eclipse is unusuably slow is an Eclipse bug. That fact that you can write unusuably slow code with GTK+ wouldn't suprise me, so installing Eclipse and saying "wow, this is slow" tells me nothing about where the fault lies. I would love to work with the Eclipse developers to make GTK+ even faster. This involves on the Eclipse side, investigating: - Why Eclipse needs performance much greater than other applications from Pango. - What operations and parts of Pango are causing problems for Eclipse. - How can those parts of Pango be tested with small test cases that don't involve pulling in a gigantic Java framework. One reason why Pango is considerably slower than stuff like XDrawString() is because Pango doesn't try to special-case and make simple scripts like low quality Latin fast, and have people be unpleasantly suprised when they run their app in Arabic, Hindi, etc. We try to make the general case as fast as possible. And note that if by "anti-aliasing turned off" you mean GDK_USE_XFT=0, this is an unsupported configuration that will be gone in the next version of Pango. There are some known performance problems with that that we have no intention of fixing.
Thank you for the weekend reply, yes I'm hoping some of the Eclipse devs weight in on this report so a dialog can get started, I've cross-posted this bug into that huge bug report on the eclipse forums. I absolutely see your point about SWT being the problem here (since no, other GTK apps are not as slow as Eclipse). And yes, what I was using to 'turn off AA' is that flag, GDK_USE_XFT... is there a better way? I've also tried turning it off using gnome-font-properties and that seemed to work fine (everything looked hideous, so I was pretty sure it was off ;) When I get back to work I'll play around with getting rid of that flag from my .gtkrc-2.0 file and using gnome-font-properties instead to adjust the AA settings. Thanks for your time Owen.
Turning it off via gnome-font-properties is the right way to do it while using supported code paths in Pango. Generally it will look hideous unless you have FreeType running with the patended byte-code interpreter enabled and fonts with TrueType hints; it's much easier to autohint fonts with AA than without. (It's also possible to point fontconfig at exactly the same bitmap fonts you are using with GDK_USE_XFT=0 by changing your fontconfig font path, but then you reintroduce all the problems of bitmap fonts.) Just to be a little more specific about what I was talking about above, what I think would be enormously useful is: - Instrument Eclipse to log all text operations to a file, and maybe some other information like "begining and expose" "ending an expose". - Perform an operation that is too slow - Look at the log, is Eclipse doing something stupid like measuring or drawing the same strings over and over and over again? Yes: Fix eclipse not to do that No: Write a small C benchmark that does approximately what Eclipse is doing. Does that benchmark show about the same performance as what is causing the problems in Eclipse: No: Investigate further why it's slower in Eclipse Yes: File a Pango bug report with your benchmark
FYI, the Pango bug in question is #129473