Red Hat’s Christopher Blizzard found that Pango is significantly slower than XFT (which itself is not a speed demon either) resulting on slower desktop Gnome/GTK+ software perfomance. The Pango maintainer, Owen Taylor, says that he’s been opposed in the past to creating a fast path for latin text because it means that the non-english code paths won’t get nearly as much testing. However, Owen now said that if we can find him a clean patch that would do it, he might take it and that “would make the entire desktop faster”. Elsewhere, the Gnome Foundation has put up a Desktop Integration Bounty.
GTK+ Challenge: Make Pango Faster; Desktop Integration Bounty
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Proof that most of the supposed slowness of Gtk, isn’t Gtk. It’s the internationalization support caused by Pango. So poo on you Gtk naysayers.
@tty: As I recall, Win95/98 never supported proper internationalization. It required the system DLLs to be recompiled for each translation, and couldn’t handle mixed-language installations. In contrast, GTK+’s internationalization support is among the best around.
@Shawn: Actually, it doesn’t prove that “most of the supposed slowness of Gtk, isn’t Gtk.” It shows one bottleneck, and doesn’t give any benchmarks showing what impact that bottleneck has overall. Your statement is just plain logically wrong. Also, for all intents and purposes, Pango is part of Gtk+. Right now, GTK+ is the only library using Pango, and Gtk+ can’t be used without Pango. Both are developed by the Gtk+ project. Practically, Pango is more a part of Gtk+ than Glib!
Why don’t they just do what Apple has done and use IBM’s ICU library ( http://oss.software.ibm.com/icu/userguide/index.html )?
It has builtin support for BiDi algorithms ( http://oss.software.ibm.com/icu/userguide/bidi.html ) and even support for glyph layout ( http://oss.software.ibm.com/icu/userguide/layoutEngine.html ). In addition it can be used in C or C++. Seem silly to not use this.
Hrmmm I’m just not so sure about this desktop integration. I think its a really neat idea and all, but my main concern comes in the building and/or installation of the packages. The problem with integration is that if one part breaks it could break other parts. Lets say gaim has to release a new patch, the patch fixes whatever was broken previously, but now breaks integration. Now your desktop messaging system, lets say email, no longer works because of it. Like I said, its all just in theory, but potential to break more stuff is there. Otherwise I’d be all for the idea.
I’d like to second the Pango is part of GTK statement. AFAIK there is no good way to draw text in GTK without pango. Pango itself can be used without GTK (I think it is only dependant on glib), but I’m pretty darn sure the reverse is not true.
Pango is the library that handles text rendering and manipulation in GTK+2/GNOME2. It is slow because it provides a lot pretty visuals(and assorted bells and whistles) at the expense of performance.
Especially startling is the fact that Pango uses Unicode(16bit characters) for all its encodings. That in addition to bi-directional output, Internalization, antialiasing, colors to mention a few is enough make most text renderers choke.
That’s why rendering with pango is a little slow. My stand is that the performance sacrifice is worth it. But I look forward to optimizations.
@Jim — Last time I checked, Pango did make use of ICU library. I can’t confirm that however.
Pango uses UTF-8, not unicode. UTF-8 is basically a modern version of unicode and is ASCII compatible.
But yes, it’s worth it. Support for foreign languages in GTK is absolutely amazing. Chinese, Japanese, Korean, you name it. They all display correctly out-of-the-box. The glib API provides very easy-to-use APIs for dealing with UTF-8. This is better than anything else I’ve seen, especially compared to the Win32 mess of unicode handling.
This is wrong, it’s clearly a Novell bounty.
Last time I checked, Pango did make use of ICU library
That would be nice to hear. But the last time I grabbed GTK it didn’t require ICU specifically as a dependency. Maybe they just took the layout engine code.
Especially startling is the fact that Pango uses Unicode(16bit characters) for all its encodings.
This might be due to the fact that it uses ICU. ICU uses 16bit wchar’s (as does Win32 under NT based systems).
“@tty: As I recall, Win95/98 never supported proper internationalization. It required the system DLLs to be recompiled for each translation, and couldn’t handle mixed-language installations. ……”
On win95, IE3 and up will do Unicode text and IE5 and up
will do Unicode input. The speed is very decent on a 32/64MB
PC.
GTK/Pango might have more features, but the speed is just too slow, even on a 3G machine.
Is this why gnome terminal is so slow?
It actually takes more cpu to scroll a maximized gnome terminal than to watch a DVD on my computer, even with bitmapped fonts.
Part of it, though “bugs” and slow algorithms account for most if it. Somewhere on the RedHat (or was it Gnome, don’t think so but..) Bugzilla there is a patch that greatly speeds things up. Beats me why it isn’t applied.
It is my opinion that Pango/GTK+ (and *any* other software in general) should be optimized to hell before proclaimed v1.0. Developers that don’t do so, I can only call them either lazy or ignorant.
It is not my intention to sound rude, but GTK+ 2.x is just way too slow in comparison to 1.2.x or Qt or FOX under the same distro (because of Pango or not). Gnome just doesn’t feel snappy, and no, it is not always the user apps to blame or X. The toolkit needs optimizations at all levels.
Red Hat, are you listening?
Pango certainly plays some role in this but I believe most of the slowness in gnome-terminal is due to the heavy reliance on xrender-(vte also paly a role in this, but I’m not sure exactly how and to what extent. Xrender is a great idea-but a) it is not particularly well supported by most graphic card drivers-ie. the free X11 nvidia driver xrender support is over 200% faster than the propietary nvidia driver from nvidia. b) according to rasterman (of enlightenment fame) xrender is sending signals across the pci/agp bus for each pixel operation which radically reduces any hardware acceleration improvements for which xrender was actually designed..
I rand renderbench from rasterman on machine yesterday-it compares imlib2 (of enlightenment fame) with xrender-remember xrender is supposed to provide hardware acceleration and imlib2 has no such hardware acceleration-pure software……
Thu Aug 5 22:42:38 CEST 2004
/usr/local/compile/render_bench
root@mtdman: pts/11: 7 files 196Kb -> ./render_bench
Available XRENDER filters:
nearest
bilinear
fast
good
best
Setup…
*** ROUND 1 ***
—————————————————————
Test: Test Xrender doing non-scaled Over blends
Time: 0.185 sec.
—————————————————————
Test: Test Xrender (offscreen) doing non-scaled Over blends
Time: 0.226 sec.
—————————————————————
Test: Test Imlib2 doing non-scaled Over blends
Time: 0.530 sec.
*** ROUND 2 ***
—————————————————————
Test: Test Xrender doing 1/2 scaled Over blends
Time: 7.183 sec.
—————————————————————
Test: Test Xrender (offscreen) doing 1/2 scaled Over blends
Time: 7.148 sec.
—————————————————————
Test: Test Imlib2 doing 1/2 scaled Over blends
Time: 0.240 sec.
*** ROUND 3 ***
—————————————————————
Test: Test Xrender doing 2* smooth scaled Over blends
Time: 147.009 sec.
—————————————————————
Test: Test Xrender (offscreen) doing 2* smooth scaled Over blends
Time: 146.457 sec.
—————————————————————
Test: Test Imlib2 doing 2* smooth scaled Over blends
Time: 3.342 sec.
*** ROUND 4 ***
—————————————————————
Test: Test Xrender doing 2* nearest scaled Over blends
Time: 116.011 sec.
—————————————————————
Test: Test Xrender (offscreen) doing 2* nearest scaled Over blends
Time: 113.510 sec.
—————————————————————
Test: Test Imlib2 doing 2* nearest scaled Over blends
Time: 2.267 sec.
*** ROUND 6 ***
—————————————————————
Test: Test Xrender doing general nearest scaled Over blends
Time: 197.022 sec.
—————————————————————
Test: Test Xrender (offscreen) doing general nearest scaled Over blends
Time: 196.513 sec.
—————————————————————
Test: Test Imlib2 doing general nearest scaled Over blends
Time: 3.862 sec.
*** ROUND 7 ***
—————————————————————
Test: Test Xrender doing general smooth scaled Over blends
Time: 303.505 sec.
—————————————————————
Test: Test Xrender (offscreen) doing general smooth scaled Over blends
Time: 304.672 sec.
—————————————————————
Test: Test Imlib2 doing general smooth scaled Over blends
Time: 8.692 sec.
ouch
according to rasterman-and supported by this benchmark on my machine(2.4 Celeron w/ Geforce 4 440mx) xrender is 30-50 times slower than pure software rendering-ie. with no hardware acceleration benefits….
Pango uses UTF-8, not unicode. UTF-8 is basically a modern version of unicode and is ASCII compatible.
UTF-8 is not a “modern version” of Unicode, it is one encoding form for the codepoint repertoire defined by the Unicode standard. UTF-16 and UTF-32 are alternative encoding forms of Unicode. Each of these encoding forms have their specific advantages and disadvantages and none is inherently better than the other ones.
As you correctly state, UTF-8 has the particular benefit of being “compatible” with ASCII codes. However, its in-memory representation of non-ASCII code points is more complex than with UTF-16 or UTF-32, and for rendering fonts on screen all code points need to be decoded anyway. Using UTF-16 for in-memory representation of Unicode encoded text data would definitely improve rendering performance.
@Karl: The thing to note in your benchmarks is that the only data sample that matters for Xft is the non-scaled one, in Round 1, where Xrender is twice as fast as imlib2. Xft2 should not be scaling the glyphs it draws, the glyph pixmaps should already be the right size (to preserve quality). So blaming Xft for slow rendering in this case really doesn’t make sense.
@Horselover Fat: While the UTF-8 representation is more complex, the extra overhead isn’t that bad when you’re doing a linear traversal of a string of codepoints (which is what you’re doing in rendering). And the overhead of dealing with the string structure would be completely overshadowed by the layout and drawing overhead.
I’ve always wondered how the Enlightenment folks where able to do all those fancy animations and eye-candy and yet keep Enlightenment extemely fast. Now I see why. I read somewhere that imlib2 is one of the fastest open source image rendering libs.(It’s said to be faster that gdk-pixbuf which GNOME/GTK uses.)
The problem with todays developers is that they all have 3GHz processors with GB(s) of RAM with other extras for kicks. I’d like to see developers use constrained resource machines to develop their apps, like in da ole days. You know, the days when Linux was hailed for being light, small and fast.
Today, I need to install Gentoo just to get the best out of my 1.4GHz Athlon with 256MB RAM. Binary distros just won’t cut it on this box. Oh, and I hear it’s only going to get worse, thanks to these new VM based languages that nobody knows how to use courtesy of their complexity.
I code on an 1800+ and sometimes a celeron 700. I test everything I do on a Cyrix 224MHz with 128MB of RAM (and before I release anything that is release I will take half that RAM out). I test on multiple Linux dists (Debian, Arch, Fedora) and I will be testing on netBSD as well. I just with I have a 64bit machine to test stuff on, but I would certainly settle for emulation.
I haven’t actually finished anything, but I will eventually
. Not all developers have fast machines. My fastest machine pretty much hits the Doom3 minimum specs. But I don’t code on any big projects, so maybe I don’t count?
Most developers I have talked to have pretty modest midranged hardware though. And many of them are as obsessive as me and they dig up doggedly slow machines to test on.
I think the pango developers just wanted something that worked well, as opposed to fast. People move to Linux mistakenly thinking it’s designed for speed.
It’s not. Windows 95/98 were speed demons (or designed with that in mind). You’ll find most *nix stuff designed for reliability and code readability. I’d say both Gnome and KDE are likely slower than Windows gui setup (explorer.exe, does that count for a good name?). However, you perceive better speed when stability is better.
There is real speed, and perceived speed. For example. Say I have an app that takes 10 seconds to open (that’s an eternity on a modern machine). If I put up a splash screen that shows progress you will perceive a shorter wait, even though the splash screen actually made you wait slightly longer. It may even open faster because it keeps people from growing impatient and trying to open it again.
It is not my intention to sound rude, but GTK+ 2.x is just way too slow in comparison to 1.2.x or Qt or FOX under the same distro (because of Pango or not). Gnome just doesn’t feel snappy, and no, it is not always the user apps to blame or X. The toolkit needs optimizations at all levels.
That’s all very well, but for the developers to do anything they really need to know exactly what is slow (difficult when you are talking about perceptions). I hear words such as snappy, but is it in specific areas – menus, text etc? Perhaps then, things can then start to be nailed down technically.
Optimizing a toolkit is easier said than done, as it depends on the way GTK is structured, its dependencies and libraries etc. It’s not just GTK, it is GTK and everything it uses as a whole. Red Hat can’t just throw resources into it just like that.
Whoever said you should design first and optimise later?!
I rand renderbench from rasterman on machine yesterday-it compares imlib2 (of enlightenment fame) with xrender-remember xrender is supposed to provide hardware acceleration and imlib2 has no such hardware acceleration-pure software……
The only one that matters here is round 1. The fact that the rest are so much slower should tell you that things are being done here that are unecessary… I don’t think this tells much of a story.
>> That’s all very well, but for the developers to do anything
>> they really need to know exactly what is slow (difficult
>> when you are talking about perceptions). I hear words such
>> as snappy, but is it in specific areas – menus, text etc?
>> Perhaps then, things can then start to be nailed down
>> technically.
Well, a good idea would be start optimizing Pango, Gdk-Pixbuf and of course the pixmap theme engine (pixmap themes are slower, but they can’t be thát slow).
That would make “Gtk+” a lot snappier already.
It is my opinion that Pango/GTK+ (and *any* other software in general) should be optimized to hell before proclaimed v1.0. Developers that don’t do so, I can only call them either lazy or ignorant.
Haven’t you ever heard of premature optimization? It’s a bad thing. It’s not worth having optimized code if it sucks. I would much rather have software that works first before it is optimized. Version 1.0 should be working code, not necessarily optimized code.
> I would much rather have software that works first before it is optimized.
GTK+ 2.x and Pango are around for more than 2 years. It *is* time to optimize.
If you’re interested in benchmarking, here’s a place to start. In gtk-demo, opening one of the “source” tabs and then resizing the window is very choppy. You can try to measure the latency between when a ConfigureNotify is received by the application, and when the application finishes all the drawing associated with that event. The first time can be noted in gdk_event_translate (in gdkevents-x11.c), and the second can be noted in gdk_window_configure_finished (in gdkwindow-x11.c). If the latency here is greater than about 100ms, then the resize will happen at less than 10fps, and it won’t look smooth. From there, you could try to see what processing is done in that code path, and add more instrumentation to determine what’s taking the most time.
I knew that AA wasn’t inherently slow because i had been playing around with an XFT version of Dillo on a p166 thinkpad and its pretty usable – not screaming fast, but definitely usable, unlike gtk+2.x for certain widgets.
I guess Owen Taylor finally pulled his head out of the sand on this one. It was funny because the rare times i would stop by #gnome on gimp.net, almost invariably there would be somewhere there complaining about gtk+ speed.
Maybe if you’re japanese or chinese, but ask that question to North Americans or Western Europeans. Gnome has lost a lot of people just for the mere fact of gtk+ slowness.
I don’t see what advanced language support has to do with speed. Yes, a powerful text renderer will be slower than a simplistic one, but if Qt can get a fully internationalized text engine to run at a good speed, than GTK+ should be able to as well. I don’t really think there is that much of a trade-off here.
Admiting that gtk/pango/gnome/whatever *is* slow is the first step. Finally!
And how many times have i heard “i don’t know what you’ve got there, here it runs fine…” *sight*. Clear and simple, Gnome *is* slow, and need some serious performance tuning. Let’s face it.
Victor.
The real question is what about good old fashion profileing…???
I mean is there a sorted list and should be an AVL tree? Does pango use the overly slow STL templates? I’m saying is someone should look at the code for the slowdown. This might all be cleared up with a simple &.
(If it’s passing structures around this would stop a copy
)
My 1 cent.
Donaldson
Well, pango is in C, so it doesn’t use the STL templates. Beyond that, the STL templates aren’t slow anyway.
Personally, I think it’s about time. I am a big GNOME/GTK+ fan but I kept switching between GNOME and KDE because of the redrawing lags (and I kept switching back to GNOME because I don’t like KDE/QT’s look and feel… Don’t ask me why, I just prefer GTK+ for some irrational reason or another). I have also heard that the next version of X11 will have an greatly improved XRENDER extention, making it finally useful.
I am sure eager to get an optimised version of both of them. I wonder why they didn’t began sooner but at least they are now doing something…
Btw, do somebody know what QT is using for rendering? It’s not using XRANDR at all, right? Or it’s doing its own internal software rendering and output the result to XRANDR?
XRANDR is the resize & rotate extention. I think you mean XRENDER
Anyway, both Qt and GTK+ draw text the same way — through Xft. Internally, Xft looks at the string to be rendered, grabs the necessary glyph pixmaps from it’s font cache (rasterizing them to a pixmap with Freetype if necessary), and then calls XRender to alpha-blend the pixmap onto the screen. The two use slightly different Xft calls, but both should generate the same calls to XRender.
Is Qt L10N’ed or I18N’ed??? (I think until KDE 2.x Qt and KDE has to be localized before displaying or proccessing asian characters)
I know GTK+ is truly an I18N’ed library…and I am REALLY thankful for that!!! The World may be one, but the customs differ. And to hell with globalization our neo-dictators try to make….
The world has to be diverse…
Qt is l18n’ed. English versions of KDE display non-english text just fine (given the right fonts).
Let me clarify. I do not think GTK+ or GNOME is slow! I however, know that Pango is slow. This is clearly evident from text rendering speeds in many GNOME and GTK+2 apps as well as benchmarks and other measured experiments.
In fact, I don’t know how any of you measure this slowness in GNOME and GTK+. I have a feeling it’s based on perception. I’d prefer benchmarks like the one provided by Karl above or the ones provided by Christopher BLizzard in the article to validate or invalidate GTK+2 or GNOME’s slowness.
Oh, and comparing GTK+1 to GKT+2 is silly.
If your benchmarks tell you it is fast, but you still perceive it to be slow.. is it not slow?
Why don’t they just do what Apple has done and use IBM’s ICU library ( http://oss.software.ibm.com/icu/userguide/index.html )?
It has builtin support for BiDi algorithms ( http://oss.software.ibm.com/icu/userguide/bidi.html ) and even support for glyph layout ( http://oss.software.ibm.com/icu/userguide/layoutEngine.html ). In addition it can be used in C or C++. Seem silly to not use this.
Good question, I didn’t even know that it was available. From the sound of it, it is very much complete, and IMHO, they might as well drop Pango and go with ICU. Sure, a little bit of a re-write for some modules, but if it results in superior internationalisation support and a speed boost in regards to performance, I say “go for it”. Nothing to lose and everything to gain.
If your benchmarks tell you it is fast, but you still perceive it to be slow.. is it not slow?
——-
means that isnt slow and that they will have to look at where the perception of slowness comes from. sometimes slowing things a bit can make stuff look fast suprisingly. just read about safari development blogs where they talk about slowing down rendering speed to make safari *seem* to be faster
They can be deceiving, and they are not always true.
Actually, I think that’s the main problem with GTK apps. It’s perceived slowness, not actual. If most worked on their cold-start times and spent more time making sure the UI is responsive even when the app is doing heavy work, people wouldn’t notice. I don’t, and most everything I use is straight-up GTK or QT. I’ve never really noticed a difference, but then most everything I use on either library is small, loads fast, and threads enough to make sure the UI isn’t ever caught in a state where it can’t draw when doing heavy work.
A big part could be that there’s just no real easy, beginner’s guide to threading a GTK app. Meanwhile, QT has it’s own cross-platform threading interface (QThread) in the library itself and excellent documentation. You can achieve something similar with g_timeout but it’s a blocking psuedo-thread, so if you do anything really substantive in it the UI will feel slow. It’s just a real pain to deal with POSIX threads. The main problem IMHO isn’t that apps are using “slow” toolkits, but that they’re not threading effeciently. Outside that, everything I’ve noticed about GTK will be fixed or will be fixable later this month when the XFIXES and XDamage extentions are released in Xorg’s server.
Mind you, I’m not speaking of GNOME’s libraries, just GTK.
I believe some sort of rendering cache should be implemented. Just like compression, you don’t want to repeatedly rendering the same patterns all the time. Of course there are a lot of repeated pattern in Latin world. For CJK Hanzi, no much pattern can be found in a short window.
Of course there are this line breaking thing which waste a lot of time. In this case, CJK is easier to handle than Latin ones.
No idea of others, bidi? Also word based, should have plenty of patterns. Hard to do line break with complex scripts.
Still even for unwrap mode, pango is quite slow.
Rayiner Hashem,
I see your point about rasterbench-the only place where xrender beats imlib2 is in non-scaled overblends-and it is unlikely that pango/vte are doing much in the way of scaling. Yet I have switched between the free nvidia driver that comes with X11 and the propietary nvidia driver-the difference between the two is that the X11 nivdia driver is at least 200% faster at 2d rendering -I don’t have the numbers in front of me-but I was trying to figure out why gnome-terminal is so damned slow- at any rate I did a `cat /var/log/messages` (the file was around 5 meg)
***********************************************************+++
/var/log/message-
51949740
`nvidia` driver
with gnome-terminal-2.7.2,pango-1.4.0,vte-0.11.10-r1,freetype-2.1.5-r1:
real 8m11.193s
user 0m0.038s
sys 0m1.001s
with xterm (XFree86 4.3.99.903(184)) -fa Andale Mono 12′ -bg black -fg white -rightbar -sl 1500:
real 0m59.042s
user 0m0.041s
sys 0m1.065s
normal xterm XFree86 4.3.99.903(184):
real 0m19.211s
user 0m0.054s
sys 0m1.208s
`nv` driver:
with gnome-terminal-2.7.2,pango-1.4.0,vte-0.11.10-r1,freetype-2.1.5-r1:
real 11m10.293s
user 0m0.036s
sys 0m0.943s
with xterm (XFree86 4.3.99.903(184))-fa Andale Mono 12′ -bg black -fg white -rightbar -sl 1500:
real 24m3.804s
user 0m0.054s
sys 0m1.053s
normal xterm XFree86 4.3.99.903(184):
real 0m24.940s
user 0m0.040s
sys 0m1.098s
***************************************************************
/var/log/emerge.log-
1784233
`nvidia` driver
with gnome-terminal-2.7.2,pango-1.4.0,vte-0.11.10-r1,freetype-2.1.5-r1:
real 0m13.268s
user 0m0.002s
sys 0m0.033s
with xterm (XFree86 4.3.99.903(184) -fa Andale Mono 12′ -bg black -fg white -rightbar -sl 1500:
real 0m14.556s
user 0m0.001s
sys 0m0.044s
normal xterm XFree86 4.3.99.903(184):
real 0m0.772s
user 0m0.004s
sys 0m0.037s
`nv` driver:
with gnome-terminal-2.7.2,pango-1.4.0,vte-0.11.10-r1,freetype-2.1.5-r1:
real 0m24.408s
user 0m0.002s
sys 0m0.044s
with xterm (XFree86 4.3.99.903(184) -fa Andale Mono 12′ -bg black -fg white -rightbar -sl 1500:
real 1m3.898s
user 0m0.000s
sys 0m0.029s
normal xterm XFree86 4.3.99.903(184):
real 0m0.880s
user 0m0.001s
sys 0m0.043s
maybe this helps to viualize the relations better:
/var/log/message:
NVIDIA nv
gnome-terminal 8m11.193s 11m10.293s
xterm w/ttf 0m59.042s 24m3.804s
xterm 0m19.211s 0m24.940s
/var/log/emerge.log:
NVIDIA nv
gnome-terminal 0m13.268s 0m24.408s
xterm w/ttf 0m14.556s 1m3.898s
xterm 0m0.772s 0m0.880s
it should be noted that there are some unsual charachters in my /var/log/messages which apparently cause some problems with rendering. This is why I alos tested it with a ‘clean’ ASCII file /var/log/emerge.log
I will let those smarter tha I draw any conclusions…
and I decided to rerun renderbench under the `nv` driver:
Sat Aug 7 11:29:27 CEST 2004
/usr/local/compile/render_bench
mtdman@mtdman: pts/19: 7 files 196Kb -> ./render_bench
Available XRENDER filters:
nearest
bilinear
fast
good
best
Setup…
*** ROUND 1 ***
—————————————————————
Test: Test Xrender doing non-scaled Over blends
Time: 15.332 sec.
—————————————————————
Test: Test Xrender (offscreen) doing non-scaled Over blends
Time: 15.527 sec.
—————————————————————
Test: Test Imlib2 doing non-scaled Over blends
Time: 0.532 sec.
*** ROUND 2 ***
—————————————————————
Test: Test Xrender doing 1/2 scaled Over blends
Time: 6.867 sec.
—————————————————————
Test: Test Xrender (offscreen) doing 1/2 scaled Over blends
Time: 6.898 sec.
—————————————————————
Test: Test Imlib2 doing 1/2 scaled Over blends
Time: 0.235 sec.
*** ROUND 3 ***
—————————————————————
Test: Test Xrender doing 2* smooth scaled Over blends
Time: 140.763 sec.
—————————————————————
Test: Test Xrender (offscreen) doing 2* smooth scaled Over blends
Time: 141.560 sec.
—————————————————————
Test: Test Imlib2 doing 2* smooth scaled Over blends
Time: 3.291 sec.
*** ROUND 4 ***
—————————————————————
Test: Test Xrender doing 2* nearest scaled Over blends
Time: 110.331 sec.
—————————————————————
Test: Test Xrender (offscreen) doing 2* nearest scaled Over blends
Time: 108.247 sec.
—————————————————————
Test: Test Imlib2 doing 2* nearest scaled Over blends
Time: 2.242 sec.
*** ROUND 6 ***
—————————————————————
Test: Test Xrender doing general nearest scaled Over blends
Time: 184.961 sec.
—————————————————————
Test: Test Xrender (offscreen) doing general nearest scaled Over blends
Time: 185.753 sec.
—————————————————————
Test: Test Imlib2 doing general nearest scaled Over blends
Time: 3.937 sec.
*** ROUND 7 ***
—————————————————————
Test: Test Xrender doing general smooth scaled Over blends
Time: 292.248 sec.
—————————————————————
Test: Test Xrender (offscreen) doing general smooth scaled Over blends
Time: 295.940 sec.
—————————————————————
Test: Test Imlib2 doing general smooth scaled Over blends
Time: 8.692 sec.
As we can see in this last renderbench benchmark-as regards the first test-“round 1”- the imlib2 rendering using the X11 native ‘nv’ driver is ~30 times faster than xrender render using the X11 native ‘nv’ driver. What is also interesting is that xrender using `nvidia` driver is 86 resp.69 faster than xrender using the `nv` driver….This case has changed recently-I am using the 1.0.6106 nvidia drivers and they apparently offer much improved xrender support compared to previous drivers…..The first time I did this test with 1.0.4xxx drivers and ‘nv’ won hands down over the ‘nvidia’ drivers in all renderbench tests….
well I tried to make a little table in my last post: all the formatting got lost…..
And WHAT? My primary language is russian, so i will still see text rendering slow like f*ck?
KDE/Qt have same, if not better, i18n support (do not know about korean, japan, etc, but for russian), but it is not slow. Somehow.
GTK+ 2.x and Pango are around for more than 2 years. It *is* time to optimize.
Your post makes no direct reference to pango and neither does mine. You are arguing with something I didn’t even say.
Is there any tool available to benchmark GTK+ themes ?
“> I would much rather have software that works first before it is optimized.
GTK+ 2.x and Pango are around for more than 2 years. It *is* time to optimize.”
Release stable software that works. Then optimize software. And that’s what they are doing now. So I don’t see what the discussion is here?
As a software developer, you don’t optimize first. You first get the software doing what it needs to do. Optimization isn’t something you can do until the software is completed. I am not talking about simple things that you can do in the language, but algorythmic(sp?) changes, and these usually affect performance even more.
To suggest as you did before that before software developers should have optimized the “hell” out of the software before a 1.0 release is not to be realistic about software development. Most developers I know (and anyone I would call a real developer) care about performance. However, software is evolutionary.
Pango may be slow, but it works. And apparently, patches to address this slowness have been rejected because they would break Pango. It’s not like the Pango developers don’t realize it’s slowness, they just aren’t going to sacrifice a working program for a speed increase. After all, if it doesn’t work, does it really matter if the speed was increased?
Let me clarify. I do not think GTK+ or GNOME is slow!
So here we go again with the “i don’t think Gnome is slow, i think it’s your perception”…
If a simple text editor (gedit) takes lots of seconds to startup, if your terminal takes lots of seconds to startup (gnome-terminal), if even your goddamn calculator takes lots of seconds to startup, and all of them consume loads of memory, than, my friend, something is terribly wrong.
Victor.
Well Victor I don’t know what kind of hardware are you using but in mine Gedit starts in one second, I think GTK redraw is slow but that have nothing to do with speed of GTK applications.
As a software developer, you don’t optimize first. You first get the software doing what it needs to do.
Having good performance is perhaps something the software needs to do. Particulary in this case when the software is a fundamental component in a graphical toolkit it would be silly to argue it didn’t need good performance.
Optmization isn’t something you can do until the software is completed.
I have to disagree with you here, it most certainly is. In fact you could argue that the sooner you start to consider the issue of performance the better the result.
I am not talking about simple things that you can do in the language, but algorythmic(sp?) changes, and these usually affect performance even more.
Replacing a slow algorithm with a fast algorithm, given they produce the same output, is a simple change. Identifying performance problems in the way the software is structured is much harder, changing the structure to achieve good performance harder still.
Pango may be slow, but it works. And apparently, patches to address this slowness have been rejected because they would break Pango. It’s not like the Pango developers don’t realize it’s slowness, they just aren’t going to sacrifice a working program for a speed increase.
Which, to me, indicates the developers of Pango didn’t consider performance when they first started crafting it. If they had, they’d already come up with numerous suggestions of how to better the performance.
After all, if it doesn’t work, does it really matter if the speed was increased?
After all, if it’s so slow it’s unusable, does it really matter if it “works”?
Well Victor I don’t know what kind of hardware are you using but in mine Gedit starts in one second, I think GTK redraw is slow but that have nothing to do with speed of GTK applications.
Yeah… (me thinks “how many times have i heard this?…”)… okay… i’ve got an AthlonXP 2000, 256MB RAM. I’m running Mandrake 10, with kernel 2.6 and all that stuff. I also have a Pentium II 64MB RAM running Debian sid.
Gedit may start a little fast if i’m not running anything but gnome. But if i’m running Firefox, with some Nautilus windows opened, Amsn… then it’s not fast anymore.
You may say i need more RAM, but that problem doesn’t happen when i’m running KDE. KWrite always starts fast (unless i’m running tons of applications, which is not the case). You just can’t compare Kwrite startup speed with Gedit.
Victor.
You may say i need more RAM, but that problem doesn’t happen when i’m running KDE. KWrite always starts fast (unless i’m running tons of applications, which is not the case). You just can’t compare Kwrite startup speed with Gedit.
——
one reason is that kde apps start something called kdeinit which then speeds up everything. its a ugly performance hack which creates problems with stuff like selinux which cant determine the process nature and control its access methods due to a generic name.
I agree with what others here have posted- GNOME is slow in regards to redraw- resizing, moving, repainting windows and gnome-terminal is quite slow at text rendering. But as regards application start up time- I have never experienced any problems with GNOME 2.x-and in fact application startup time has improved with every release since 2.x came out-on my machine there is no comparison in terms of startup speeds between KDE and GNOME- GNOME wins always hands down-and yes I even have KDE-3.2.3 prelinked….None of the speed factors I have encountered with GNOME actually approach issues of usability it is more a question of disliking actually seeing windows being redrawn-in terms of perception it *seems* really slow and in terms of gnome-terminal speed as regards rendering text it is objectively slow-slower than any other terminal app which I have used….
Your Athlon machine is more than sufficient for GNOME to have good startup speeds-your pentium 2 does not have enough ram for decent performane under either KDE or GNOME… do you have dma turned on for your harddrive ? which version of GNOME are you using ? I have never used GNOME under Mandrake-but I suspect GNOME support under Mandrake is similiar to under SuSE ie. lousy….
That’s right, that’s because KWrite has started in the background w/o you to know it, even if you never run it, it still be there wasting memory.
I agree with what others here have posted- GNOME is slow in regards to redraw- resizing, moving, repainting windows and gnome-terminal is quite slow at text rendering. But as regards application start up time- I have never experienced any problems with GNOME 2.x-and in fact application startup time has improved with every release since 2.x came out-on my machine there is no comparison in terms of startup speeds between KDE and GNOME- GNOME wins always hands down-and yes I even have KDE-3.2.3 prelinked….None of the speed factors I have encountered with GNOME actually approach issues of usability it is more a question of disliking actually seeing windows being redrawn-in terms of perception it *seems* really slow and in terms of gnome-terminal speed as regards rendering text it is objectively slow-slower than any other terminal app which I have used….
Your Athlon machine is more than sufficient for GNOME to have good startup speeds-your pentium 2 does not have enough ram for decent performane under either KDE or GNOME… do you have dma turned on for your harddrive ? which version of GNOME are you using ? I have never used GNOME under Mandrake-but I suspect GNOME support under Mandrake is similiar to under SuSE ie. lousy….
If you try to start KDE apps under Gnome of course it will be a lot slower than Gnome apps, because it has to load the entire KDE framework.
But if you start KDE apps under KDE… boy, it’s much faster than Gnome. And, honestly, i’m not the only one who says that.
Oh, and come on, Mandrake is great, let’s not blame Mandrake… whatever distro i install will be more or less the same speed.
And yes, Gnome slow redraw is also very annoying.
Victor.
I can’t tell you what causes gnome apps to take so long starting up on your machine-I pointed at the distro, in this case mandrake, because if you compile gnome yourself you would see that it is not particularly slow regarding startup speed-nowhere near your claims of speed issues effecting usability….
And even if I have KDE apps already running, ie. the framework has been loaded already- GNOME apps on my machine still start up faster than KDE apps….gedit starts significantly faster than kate on my machine-but *significantly* is rather an overstatement- startup speed is not an issue on my machine for hardly any apps-openoffice could be faster but (13 seonds first time -6 seconds thereafter)… an no I do not have a *really* fast machine(2.4 GHz Celeron, 768MB RAM, WD 120GB w/8MB cache, Geforce4 440 mmx)-its not slow but there are much, much faster machines out there-an athlon XP 2000 is in most things faster than a 2.4 GHz Celeron…..
Someone(Mystilleef?) earlier mentioned developers all having 3GHz machines and how they should have older machines for designing software so as to be forced to work on optimization-this is silly-of course paid developers working at Redhat, Novell and SUN do have nicer, newer machines but most independent devs/hackers that I have encountered or had contact with tend to have quite meager machines-probably averaging around 700-800Mhz Pentium3’s/Duron`s…..
that the blog posting which mentions pango speed was actually about the speed of pango being used as the text layout part of Mozilla ?
Kwrite does not start in the background without you knowing it. It starts on demand, just like every other KDE app except Konqueror.
I wasn’t talking about Kwrite application, Im talking about the libs Kwrite use, witch are loaded in the background before Kwrite.
Read your own post:
That’s right, that’s because KWrite has started in the background w/o you to know it
You didn’t say anything about libraries — you said KWrite itself started in the background.
In any case, yes, the libraries are loaded before-hand. But KDE apps all use the same libraries — and they’re all shared. So kdeinit only wastes memory if you’re running it, but no any KDE applications. In a normal desktop, where you’re running at least Kicker and some KDE applets, the one-time cost of kdeinit doesn’t really impact memory usage.
my bad, I was writing implicit.
Profiler…. I knew you could
also, You design with the major optimizations in mind or they will never get done. I have made a career of fixing people’s code for this very reason.
O I will just use a sorted list , or I’ll just pass a struct around. Speed is part of design not an afterthought.
Donaldson
also, You design with the major optimizations in mind or they will never get done.
I’m glad that most OSS/UNIX programmers don’t think this way. None that I know of at least. If they did we would all have to deal with broken and insecure applications. If I wanted that I would be using Windows.
also, You design with the major optimizations in mind or they will never get done. I have made a career of fixing people’s code for this very reason.
Optimization is an afterthought. If you’re a good coder it shouldn’t be hard to go back and optimize slow algorithms. If the code is a mess it becomes a lot harder to do. If you don’t even have a working product how do you expect to test it?
In Unix philosophy, “Premature optimization is the root of all evil.” In other words, optimization is usually the last phase in the development process. And that is after code is working correctly, and has been extensively tested.
The root of all evil in code is not optimization it’s being lazy. Coders think they can use a quick easy hack to code something up in the front end and then “fix” it later. The classic example is searching or sorting a list. The coder would have been better served to use a threaded AVL tree when writing the code thus the fixing would never needed to be done.
The optimizations that are he evil involve cpu/ low level stuff. Usually code wrapped within #ifdef etc. But for a programmer to say while writing the code, “Should I pass a pointer or the whole structure” that is just good design. Yet time after time I go to fix a corporations code and I find places where programmers never stopped to ask them selves simple design questions.
This leads me to the point of programmers calling themselves engineers. bullshit. And engineer designs something from the ground up to work within a set of guidelines. Pango failed on this account. They built something that was too slow when they started and even after all of the hardware upgrades it’s still too slow. A software Engineer (A true one) would have aborted this code early and made the correct design decisions to avoid needing to go back and fix performance.
All code will need or maybe desire some sort of low level tweaking in the end, but if Your cpu utilizations drop by 50% or more by this final polishing then you did something wrong while writing this code.
My 2 cents
Donaldson
P.S. Still my root question is still there.. Which procedure in Pango is the cpu hog????
Pango has neither failed in its objective, nor is it a CPU hug. Pango takes its time to render and layout out text correctly in any language. The tradeoff, unfortunately, is speed.
P.S. Still my root question is still there.. Which procedure in Pango is the cpu hog????
Since you allude to be the great designer, profiler and engineer, I think we should be asking you that question. After all, last time I checked, Pango’s source code was open and free to scrutinize. Tell us where exactly Pango has failed, why it is slow, and a summary of what your profiling tools are suggesting.
Your suggested improvements are very welcome.
Generally, non-optimized code is NOT the product of lazy developers. It is usually the product of an aggressive schedule. Everything takes time. Optimization takes time that could be used developing features or fixing bugs. Another thing about optimizations is that they usually result in less flexible code, making future changes more difficult. I’m not saying that optimizations shouldn’t be done, I’m just saying there is a cost. If every project waited until every feature was complete, all bugs were fixed, and everything was heavily optimized, nothing would ever get released. Everyone is trying to do their best with limited resources.
While it may not have been your intention to sound rude, calling developers “lazy or ignorant” IS rude.