GTK+ 2.8.0 Released

157 Comments

1. 2005-08-13 8:34 pm

   poundsmack

   best GTK release ever. i hope
• 2005-08-13 8:38 pm

  Thom Holwerda

  first post

  Be prepared to be the first to post on this release throughout the *entire* internet; I posted this news only a few minutes after the official announcement came in the email .
2. 2005-08-13 8:48 pm

   Anonymous

   This is really nice, but when will the Cairo stuff be used by programs? Also, when this is done, canw expect GTK+’s redraw issues to go away?
• 2005-08-13 8:50 pm

  ma_d

  My understanding: When someone writes a theme engine to use it.

  Other than whatever just works differently under the scenes: Which I’d imagine is quite a few small details.
• 2005-08-13 9:01 pm

  Rahul

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

  Cairo is already used by several programs like poppler which forms the basis for Evince now in GNOME 2.12. Redrawing should be much more smoother.
• 2005-08-13 10:04 pm

  J. M.

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

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

  This is what Richard Stellingwerff says about it:

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

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

  And now, instead of finally doing something about it, they make it even slower.
• 2005-08-13 10:12 pm

  Anonymous

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

  Unacceptably slow my ass. GTK might not be the fastest toolkit but it’s acceptably fast. Just because people complain doesn’t mean that it’s the most important issue. People will always complain no matter what you do.
• 2005-08-13 10:18 pm

  J. M.

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

  I have no reason to believe it. The GTK+ programmers have proved to be incapable of doing anything significant about the performance for years. How many times have we heard “with time, the speed problems will be fixed”? And the result – nothing.
• 2005-08-13 10:24 pm

  Anonymous

  So the recent optimizations don’t count? It seems you’re only interested in slandering the GTK developers. Grow up.

  Pretty much the only situation in which you notice the slowness is when resizing windows. Do you resize windows all day long, non-stop? Can you wink your eye faster than GTK can draw a button? No? I thought so.
• 2005-08-13 10:41 pm

  J. M.

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

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

  Best

  Can you give some more information about your hardware?

  I’m unable to duplicate any of these complaints on my 2.8GHz CPU. I get split second response on all the operations. Unless your system is swapping constantly, none of these should take more than a second.
• 2005-08-13 11:41 pm

  ldouglas

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

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

  I found that response to be disappointing. Not because I have a problem with the speed, personally. But because GTK does have a reputation for slowness among users and the developer seemed so totally oblivious to their concerns.
• 2005-08-13 11:54 pm

  J. M.

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

  kaiwai

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

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

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

  japail

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

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

  japail

  ‘contributions rejected’
• 2005-08-14 1:01 am

  ldouglas

  japail,

  So are you saying that no one has ever been able to provide enough detail to pinpoint the trouble-spots or prove to the developers that a problem exists, and that the developers are, for some reason, unable to profile their own code?

  That sounds worse than the original claim of simple complacency. 🙁
• 2005-08-14 1:06 am

  Rahul

  ”

  So are you saying that no one has ever been able to provide enough detail to pinpoint the trouble-spots or prove to the developers that a problem exists, and that the developers are, for some reason, unable to profile their own code? ”

  Developers profile and do performance improvements on a periodical basis. Unless you have any specific complaints just telling developers that GTK or GNOME or Linux or anything for that matter is slow isnt useful at all
• 2005-08-14 1:29 am

  ldouglas

  > Developers profile and do performance improvements on a periodical basis. Unless you have any specific complaints just telling developers that GTK or GNOME or Linux or anything for that matter is slow isnt useful at all

  So, other tool kits just have better bug reporters… or maybe just users who don’t complain so damn much. Good to hear it has nothing to do with the developers. 🙂

  Anyway, like I say, GTK2-2.6.7 seems adequately fast on my GeForce 6800 GT APG 8x card with 256MB of DDR3 in an AMD64 2800+/1GB PC3200. So I’ll leave the users with GTK performace problems to fend for themselves.

  Like in anything else, if you don’t take care of the customer, someone else will. And its not like GTK users don’t have a choice.
• 2005-08-14 2:56 am

  Rahul

  ”

  So, other tool kits just have better bug reporters… or maybe just users who don’t complain so damn much. Good to hear it has nothing to do with the developers. 🙂

  ”

  Unless you have specific complaints nobody can fix any problems. Thats universal
• 2005-08-14 4:42 am

  Anonymous

  Unless you have specific complaints nobody can fix any problems. Thats universal

  Well, how specific must it be? When someone reported to the KDE developers that moving the mouse cursor over the tabs with Plastik theme consumed more CPU cycles than the user liked, they fixed it.

  Now, if I say that when I click on a combo box or any similar widget (i.e. open it), the CPU meter stays at 0 % in all toolkits – except for GTK+, where it always jumps to 2-3 % (1 s average) or even more, it would probably be considered ridiculous, unimportant, vague and useless by your standards.

  But it’s true.

  Why, when I drag and drop some object/icon in MS Windows, the CPU stays at 0-4 %, while with GTK+, the same task needs 20-30 % CPU? Is it unreasonable to say “because the GTK+ implementation of drag’n’drop is inefficient”?

  Now, this is not some vague statement, without saying anything specific. This is my real-life observation, one of many, many specific things I see every day using GTK+ and other GUI toolkits and software and comparing them.

  So if this is not what the GTK+ developers want to hear, they should say it. They should say – “find where the inefficiency is in the source code and fix it yourself”. Fair enough. But you say you just want to hear something specific. And these are just one of many specific real-life examples. When you see that right-clicking and opening a menu consumes several times more CPU cycles in GTK+ than it does in other toolkits, I think this could be enough information to any competent GTK+ programmer where to start looking, profiling etc. But if they dont wan’t to hear that, they should say so.
• 2005-08-17 10:57 pm

  Anonymous

  Gtk on MS Windows has poor performace? I WOULD NEVER HAVE GUESSED!

  I still don’t care about Gtk on MS Windows and neither should you.
• 2005-08-14 11:27 am

  Anonymous

  Hello? How the hell do you expect developers to fix your problem if they can’t even reproduce it themselves?!
• 2005-08-14 3:30 am

  rayiner

  Actually, when the layout is complex and the EXPOSE handling gets backed up, yes I can wink my eye faster than GTK can draw a button. Well, on my laptop, anyway…
• 2005-08-14 3:32 am

  rayiner

  Oh, and gnome-terminal deserves a special place in hell. SBCL’s “compiling from source” page actually singles out gnome-terminal and OS X’s terminal, pointing out that you shouldn’t try to compile SBCL from those programs because they’re slow handling of the compiler’s output will dramatically increase your compile time.
• 2005-08-15 1:36 am

  ma_d

  screen

  make

  #click close window

  #wait an hour

  screen -r

  🙂
• 2005-08-14 2:42 pm

  Anonymous

  > So the recent optimizations don’t count?

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

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

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

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

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

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

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

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

  g2devi

  Which Gtk2 app are you referring to?

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

  Anonymous

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

  And I mean any Gtk2 app.
• 2005-08-14 7:25 pm

  g2devi

  I haven’t had redraw or speed problems in FVWM and XFCE, so perhaps KWin (the KDE Window Manager) has an interaction problem with Gtk2 on your system or something else is wrong with your Gtk2 installation? Gtk2 uses double-buffering for its redraws so earlier redraw problems (which was actually the result of too agressively updating), shouldn’t be a problem.

  Which distribution are you running and what’s your hardware and other configuration? (Distribution name, Distribution version, KDE version, Gtk2 version, memory, swap space, if Gtk2 was manually installed or preinstalled, etc)
• 2005-08-14 8:08 pm

  J. M.

  I haven’t had redraw or speed problems in FVWM and XFCE, so perhaps KWin (the KDE Window Manager) has an interaction problem with Gtk2 on your system

  Yes, KWin has interaction problems (not only) with GTK+. Resizing GTK+ windows is much smoother in Metacity and oher window managers than it is in KWin. KWin is the slowest window manager I’ve seen (and not only with resizing). But its not just KWin – I’m just running GTK+ in IceWM and even though it’s much faster than KWin, there’s still some resize lag with GTK+, and perfectly smooth resizing with Qt. But by far the worst interaction problems can be seen on Windows – the Windows version of GTK+ doesn’t react on window resize at all until you release the mouse button, which looks absolutely horrible.

  But resizing problems are only a tip of the iceberg, GTK+ has much more performance problems than just resizing. And yes, you can se them in KDE, too (when you compare it e.g. with Qt apps), KWin does not influence that. People always talk only about resizing and redrawing as if it was the only performance GTK+ had. Far from it. See the earlier posts (it’s obvious and measurable that GTK+ consumes more CPU cycles for many common tasks than other toolkits do).
• 2005-08-14 8:22 pm

  Anonymous

  You’re kind of missing the point. The “excersize” was meant to demonstrate what happens if you introduce a single Gtk2 app into a pure QT environment (KDE). Once you launch a Gtk2 app it “seems” to introduces a bottleneck that impacts rendering/re-draw performance of QT. Without being familiar with the internals of Gtk2 I can’t pinpoint the problem, only describe it. If you are running XFCE then there you have it, another Gtk2 based environment like Gnome – meaning – you don’t have a pure QT environment to compare with as Gtk2 is always there drawing *some* part of your desktop (docker, context menus etc). If you turn off all animations maybe it’ll be easier to spot.

  If you feel my specs would give you some insight at what I’m getting at then here ya’ go:

  Software:

  Slackware current

  Gtk+ v2.6.8 (and all it’s dependencies)

  Qt 3.3.4

  2.6.11.11 kernel

  KDE 3.4.2

  Relevant Hardware:

  Athlon T-Bird (1.4GHz), 500Mb RAM

  Nvidia FX5200 (with Nvidia’s binary drivers)

  All of these are stock binaries except for the kernel.

  Anyway, no offence to any Gtk developers reading OSNews (the tookit is good) – it’s just one of those observations that bugs me to no end, in any case this is my last post on the subject since I can’t describe it any better than this.
• 2005-08-14 9:14 pm

  Mystilleef

  And your assumption is that GTK+ developers hack on GTK in KDE?
• 2005-08-14 3:33 pm

  Anonymous

  On the other hand, i have no significant reason to even beleive their is a speed problem and I am using an older athlon XP.

  I think most people bitching about speed are either trolls or just have nothing better todo.

  for most things, it works and is pretty fast. im sorry if milliseconds bother you, may i suggest some pot, that will calm you down. becaus that tiny delay here and there doesnt bother a normal human being
• 2005-08-13 11:15 pm

  Daniel Borgmann

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

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

  Anonymous

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

  Unfortunately, scaling is bunk. Yes, it does mean I can make it look the same at 1600×1200 as it does at 1024×768, just that it will be crisper. But when I switch from 1024×768 to 1600×1200 I want more viewable size, so I want it to shrink anyway.
• 2005-08-14 1:45 am

  Daniel Borgmann

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

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

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

  In a vector world you could make your interfaces take up as few space as you want, independent of your screen resolution. That’s how it should be. It works for fonts, why not for the rest of the GUI?
• 2005-08-14 2:45 am

  ma_d

  I think it’d be possible to implement caching of renders. Cairo may already do that. But it should be rendered live at some point, not in advance; it’s not that heavy a thing to do (like compiling) that you need to do it in advance for everyone.

  It may turn out that you can render the svg’s with a small efficiency loss: I wish I knew more about it though.
• 2005-08-14 3:36 am

  rayiner

  Scaling isn’t bunk, you’re just confused. Scaling happens with DPI, not resolution. Ergo, if you switch from 1024×768 on a 17″ monitor to 1600×1200 on a 20″ monitor, the sizes should remain the same, since both are around 96DPI. However, if you go to 1600×1200 on a 133dpi LCD, or 3200×2400 on a 200dpi LCD (like IBM’s or Viewsonic’s), you damn well want the sizes to change!
• 2005-08-14 1:03 am

  Anonymous

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

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

  BTW XFCE is based on GTK+. Think what this must mean.
• 2005-08-14 12:43 pm

  chip_0

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

  1c3d0g

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

  Uhm… pardon me, but isn’t Firefox based on a language developed by Mozilla (XUL)? Or is that something else entirely? ‘Cause for instance in Winbloze I don’t need to have the GTK+ toolkit installed to install and use Firefox.
3. 2005-08-13 9:02 pm

   STTS

   May be i miss something but did GNOME 2.12 beta use cool Cairo AA feature to smooth rounded window corners ? I can see ugly pixels, same as on pre-Cairo 2.10 desktop. Or it is up to theme developers ? Color chooser look nice.
• 2005-08-13 9:24 pm

  Anonymous

  its up to the theme developers
• 2005-08-14 3:29 am

  rayiner

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

   Anonymous

   The release notes say “Most of the rendering of GTK+ widgets is now done with cairo.”, so if cairo is compiled with glitz support, pretty much everything should be faster. Has anyone tested this yet? I am going to try the speed with the gtkperf-program, which does what the name says: tests GTK performance..

   -WereCat
5. 2005-08-13 9:29 pm

   Anonymous

   http://www.stellingwerff.com/?p=5 – it’s on it’s way people…
6. 2005-08-13 9:38 pm

   Anonymous

   That theme looks excellent.

   I can’t wait until it’s fast enough to use.
• 2005-08-13 10:52 pm

  Daniel Borgmann

  Just wait until you see the candy theme we are working on in parallel. It makes Aero look shabby.
• 2005-08-14 3:08 am

  Anonymous

  You haven’t event seen aero my friend… so this is speaking out of your arse.
7. 2005-08-13 9:41 pm

   Jackson Brown

   Call me when they don’t look like shit
8. 2005-08-13 9:46 pm

   Anonymous

   with an attitude

   ps cairo is gay
9. 2005-08-13 10:03 pm

   Anonymous

   Will this lead the way to redoing the GDK drawing model? that would be great, since the current thinly wrapped X model is a major PITA to work with.
• 2005-08-13 10:09 pm

  Anonymous

  As far as I know Cairo *is* the new GDK drawing model. In other words, they’ll use Cairo instead of GDK for drawing everything.
10. 2005-08-13 10:15 pm

    Anonymous

    I just did try and install glib-2.8.0, cairo-0.9.2, pango-1.9.sumthin and gtk+-2.8.0 but I couldn’t make it work… =( Gnome loaded up, but I got errors about the mixer applet and Galeon wouldn’t start up, neither did gtkperf. Darn. Moving the console window around did stop for a moment and continue moving again..

    -WereCat
• 2005-08-15 1:24 pm

  Anonymous

  You probably forgot to compile atk
11. 2005-08-13 10:34 pm

    morganth

    If someone would only post a nice article for how to properly profile a complex *NIX library like GTK+, then maybe some fresh programmer eyes would start looking at it. In other words, a nice expansion of this stub would be useful.

    http://live.gnome.org/MemoryReduction

    I, for one, would love to work on optimizing GTK+, if I only knew where to start.
• 2005-08-14 12:18 am

  irasnyd

  Agreed. If someone will post places in the code that need looking at, I’ll definitely take a look. Maybe some smaller stuff at first, but I’ll work up the skills.
12. 2005-08-13 10:35 pm

    Anonymous

    I am using GTK+ with cairo for some days now and havent noticed any speed issues about it. For those who finds it hard to believe :

    Without cairo:

    GtkPerf 0.30 – Starting testing: Sun Aug 7 21:46:49 2005

    GtkEntry – time: 0,03

    GtkComboBox – time: 1,24

    GtkComboBoxEntry – time: 1,13

    GtkSpinButton – time: 0,16

    GtkProgressBar – time: 0,05

    GtkToggleButton – time: 0,59

    GtkCheckButton – time: 0,51

    GtkRadioButton – time: 0,55

    GtkTextView – Add text – time: 0,90

    GtkTextView – Scroll – time: 0,60

    GtkDrawingArea – Lines – time: 0,32

    GtkDrawingArea – Circles – time: 0,44

    GtkDrawingArea – Text – time: 0,87

    GtkDrawingArea – Pixbufs – time: 0,03

    —

    Total time: 7,41

    With cairo:

    GtkPerf 0.30 – Starting testing: Sun Aug 7 21:48:05 2005

    GtkEntry – time: 0,04

    GtkComboBox – time: 1,22

    GtkComboBoxEntry – time: 1,11

    GtkSpinButton – time: 0,16

    GtkProgressBar – time: 0,05

    GtkToggleButton – time: 0,57

    GtkCheckButton – time: 0,49

    GtkRadioButton – time: 0,53

    GtkTextView – Add text – time: 0,89

    GtkTextView – Scroll – time: 0,59

    GtkDrawingArea – Lines – time: 0,31

    GtkDrawingArea – Circles – time: 0,43

    GtkDrawingArea – Text – time: 0,87

    GtkDrawingArea – Pixbufs – time: 0,37

    —

    Total time: 7,64

    As you see most things are faster in gtk+ with cairo. The only thing that is slower is GtkDrawingArea – Pixbufs which was impossible to notice in practical using of Gnome.

    The other thing is that cairo is going to imporve and with glitz in future it should many times faster so please stop this nonsence about cairo being slow. I’m shure most of those who says it hasn’t even tried it.
• 2005-08-19 2:40 am

  Anonymous

  “impossible to notice in practical using of Gnome”

  But It is noticeable,the window area shows black for quite a short time when redrawing.
13. 2005-08-13 10:44 pm

    Anonymous

    Im ready to download the first distro that comes with it.
14. 2005-08-13 10:47 pm

    Michael Dominic K.

    The upcoming Gnome 2.12 will depend on Gtk 2.8 .
15. 2005-08-13 10:49 pm

    Anonymous

    The upcoming Gnome 2.12 will depend on Gtk 2.8

    Is great to heart that, I can’t waith for a new brand of Ubuntu with the new GTK beauty.

    Good job GTK team.
16. 2005-08-13 10:54 pm

    Anonymous

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

    Come one man, put a screenshot, we want to see.
• 2005-08-13 11:36 pm

  Daniel Borgmann

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

  Ahem, we pretty much just started so it’s still far from being complete, but this might give you an idea:

  http://213.133.111.182/Temp/Screenshot-Calculator.png

  Still very rough and the buttons look a little better by now, but that’s about the style we are shooting for.
• 2005-08-13 11:42 pm

  Anonymous

  So… it looks better than Aero by looking similar to the Brushed Metal theme from Apple? I would prefer Geramik to that.
• 2005-08-13 11:50 pm

  Daniel Borgmann

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

  At least we are better at looking similar to Brushed Metal.

  http://www.pcmag.com/slideshow_viewer/0,1205,l=&s=400&a=156757&po=3…

  That kind of chrome look is very common anyway. What matters is the quality of the picture.
• 2005-08-14 12:02 am

  Anonymous

  “At least we are better at looking similar to Brushed Metal.

  http://www.pcmag.com/slideshow_viewer/0,1205,l=&s=400&a=156…

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

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

  -WereCat
• 2005-08-14 12:09 am

  Daniel Borgmann

  Well maybe you should wait for the actual theme to be ready before you judge it to be “heavy and unfriendly”. We are still mostly experimenting.
• 2005-08-14 4:56 pm

  Anonymous

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

  I like the direction you are going with it.
• 2005-08-14 12:21 am

  japail

  I don’t really like either of the two, but I’d probably say aspects of the Vista shot are better. The color-coded Dr. Mario titlebar in the other screenshot coupled with the “metal” look just doesn’t do it for me. I like darker colors, but the split-color button faces look a bit corny.

  http://213.133.111.182/Temp/Screenshot-The%20Widget%20Facto…

  Plus the color selection for menus in both shots are fairly harsh contrasted with the dull gray.
• 2005-08-14 1:30 am

  Daniel Borgmann

  Really now, I just posted the screenshot to give you an idea. Knowing us, the end result probably will be totally different anyway. This is a more recent shot:

  http://213.133.111.182/Temp/Screenshot-Calculator5.png
• 2005-08-14 2:54 am

  Best

  How are the themes being made? How difficult is it to make one? I’d like to try making one soon as an experiment. Is the source available yet?
• 2005-08-14 3:31 am

  Daniel Borgmann

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

  If you know C it’s not difficult, as Cairo has a fun API to work with. But I don’t know if there is any complete Cairo theme yet, so you are probably better off waiting for one, unless you feel like writing the missing parts from scratch. clearlooks-cairo and blackrock are in Clearlooks CVS on sourceforge.

  If you are an artist, then it would probably be easier to make mockups for others to implement. Pretty much everything that can be done with Inkscape can also be done with Cairo.
• 2005-08-14 3:39 am

  ma_d

  Ask the clearlooks author.
• 2005-08-14 3:20 am

  Anonymous

  Well, again, what you’re trying to copy _is not aero_. Aero was not even revealed yet by Microsoft. It will be available with the next beta or the RC series.
• 2005-08-14 3:25 am

  Daniel Borgmann

  Then replace “Aero” with “whatever Microsoft is currently demoing in Vista Beta”. I don’t really give a damn. (And of course we are not trying to copy anything.)
• 2005-08-14 3:28 am

  Anonymous

  Well, ok I might be a bit harsh. I like that you’re trying new UI for GNOME but I just wanted to be clear that this cannot be known that is better than Aero as of now…

  cheers
17. 2005-08-13 11:23 pm

    Anonymous

    haha not related to gtk, but those ads for the voip with the orange background have horribly photoshopped characters in them.
18. 2005-08-13 11:41 pm

    Anonymous

    Looks very nice, I like it, you were right about that theme.
19. 2005-08-13 11:49 pm

    Anonymous

    Isnt all this cairo stuff all about “special effects”?..

    like onMouseOver do some fancy animation?

    like enlightenment parts do?…
• 2005-08-13 11:51 pm

  Daniel Borgmann

  No, Cairo is only about drawing.
20. 2005-08-13 11:55 pm

    Anonymous

    I’ve just tried blackrock theme from clearlooks cvs. As I understand it’s cairo based. Tried gtkpref and it shows Total time: 6,70. How does it come that it’s even more faster than gtk without cairo?
• 2005-08-14 12:02 am

  Daniel Borgmann

  Well it’s still very incomplete, so most widgets are using the default style and some might even just draw nothing. No wonder that’s fast. You could probably get more meaningful results by just comparing the button benchmark times.
21. 2005-08-14 1:01 am

    Anonymous

    GTK isn’t the only project that uses (or will use) cairo. Not in the least. Gecko 1.9 will use Cairo exclusively for all of its graphics drawing, including SVG, CSS effects, XUL, and even plain HTML.

    http://weblogs.mozillazine.org/roadmap/archives/008240.html

    OpenOffice.org will also use Cairo in future versions, though I have less info about that.

    http://rodo.foo.cz/blog/?p=10

    And you can be sure the Mozilla Foundation and the OpenOffice.org guys will do work to make sure Cairo is as fast, if not faster, than what it used earlier.
22. 2005-08-14 1:50 am

    Anonymous

    Really now, I just posted the screenshot to give you an idea. Knowing us, the end result probably will be totally different anyway. This is a more recent shot: