Home > GTK+ > GTK+ 2.8.0 Released

GTK+ 2.8.0 Released

GTK+ 157 Comments

GTK+ 2.8.0 has been released. You can download it from here, and read the release notes here. GTK+ 2.8.0 depends on the Cairo vector graphics library for rendering most of the GTK+ widgets, bringing graphics capabilities as antialiased shapes, alpha blending, and gradients.

About The Author

Thom Holwerda

Follow me on Mastodon @[email protected]

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?…

  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:

  • 2005-08-14 3:58 am
    ldouglas

    I’m surprised that so much is being said about eye candy and image quality on screen, and so little is being said about the supposed equivalence of on-screen and printer rendering.

    I’ve long been happy with what I see on the screen, but all too often when I go to print (and you can read that as meaning “get ready to show something to someone else”, the result is embarrassing.

    I already have more on-screen eye candy than I care for. But if Cairo can provide WYSIWYG printing, that’s a *big* step forward.

    • 2005-08-14 5:59 am
      Anonymous

      I’ve heard that Cairo will improve printing as well. Apparently whatever is rendered on the screen with Cairo will appear the same way when printed. ;) I’m soo excited about playing with all this new stuff in Breezy!

  • 2005-08-14 6:13 am
    Anonymous

    First, let me preface my comment by saying that I use XFCE as my primary desktop, and I love GTK+, it’s my favorite toolkit.

    The person who pointed out it ran fine on their 2.8Ghz machine hit the nail on the head. That’s a really ***** fast machine. Try running GTK on a P3-450 and see how it runs. Back when that was my primary desktop, I avoided GTK and Qt like the plague, those things were butt-slow.

    I don’t particularly have any problems with GTK on my 2Ghz laptop, but every now and then it bogs. I’m not too worried about it, but I’d like to see GTK work on improving the speed so it’s a more viable toolkit for slower machines. I guess if Cairo makes it easier for them to program their toolkit, they should go for that and make optimizations later. But many of us do want the speed optimizations, but how does anyone have the assurance that the next big wizbang thing won’t take priority then?

    • 2005-08-14 6:41 am
      timosa

      I am running GNOME of Ubuntu 5.04 in 550 MHz Athlon with 256 MB RAM and it’s fast enough. Even if KDE seems to be slicker GNOME is still fast enough and very usable with my configuration.

      • 2005-08-14 1:40 pm
        evangs

        I have a Dell Inspiron 3700 laptop from 1999. It has a Celeron 433 MHz processor, with 256 MB of RAM. I run Ubuntu Hoary on it, and GNOME runs fine. Not blazingly fast, but much better than Windows XP on the same desktop. Even my wife likes it better than Windows, and she’s anything but a geek.

  • 2005-08-14 8:33 am
    Anonymous

    I think the main problem why the GTK people get vague reports is that rendering speed unless it is really broken is very subjective and hard to pinpoint towards a single problem.

    And there probably is not a single point which causes the speed problems, but a myriad of points and hard gruntwork.

    The perfect example for this problem is javas Swing, which faced the same problem and went through years of optimization and now is faster than GTK2 (but slower than Qt), the main point in Swing was, that at one point the devs gave up the optimizations because to many points in the old code caused the speed problems, and did a total rewrite while maintaininge the interfaces, also they started to pull some stuff into the acceleration code of the underlying platform.

    Yes CAIRO is slow for now, but it is a solid foundation which in the long run can be docked onto the underlying accelerator functions of the graphics card, so basically making things slower in the beginning by moving towards Cairo will make things faster in the long run.

    (Similar to the Swing/Java2d layer, where the main speed increases came from moving the buffering and vectorization code in Java from the pure java layer onto the graphics card)

  • 2005-08-14 8:47 am
    STTS

    Two month ago I download E17 and it feels like step two generation hardware upgrade on one of my home box (Cel300@433 MatroxG200 128 RAM). May be it is bad double buffer implementation, may be gcc is not hi-end in code optimizing, may be it is more careful work with backtrace interrupt, less CPU cache trash, but Cel433 feel faster than my second box (AthlonXP 2500+@3200+ Radeon 9800Pro 128 1gb RAM) with GNOME 2.10 on FC4. I talking about mouse aiming/click and waiting to get a visible changes. Most noteable issue is when i click “application” menu button sometime menu appear immediately but most time it is so late that i think my mouse (Logitech MX510) or kernel loose event and click button again and again (no swapping/background tasks/angry applets/services/network activity on both boxes). E17 do it so fast so i feel like it predict my moves ;) . GTK+ 1.X never have such issues, maybe it is because GTK+ 2.0 introduce anti-flicker double buffering ? XP on same box (Athlon2500+) feel much slower then E17 but definitely faster then GNOME. There is no benchmarks that measure mouse button pressing and monitor surface pixel lightning so dont tell me your API call timings, it is useless in real life.

  • 2005-08-14 8:53 am
    Anonymous

    Just get used to it folks. Once KDE slims down in the bloat area with it’s user interface and makes it more user friendly you will see a slow but steady migration away from Gnome and it’s dog slow GTK api.

    • 2005-08-14 11:35 am
      Anonymous

      Trolls have been claiming that for YEARS now.

      1999: GNOME will die, long live KDE!

      2002: GNOME will die, long live KDE!

      2005: GNOME will die, long live KDE!

      And today, GNOME is still alive and kicking, and still has a large user base.

  • 2005-08-14 8:57 am
    Anonymous

    Great, i have already downloaded this new release, which has a bunch of issues (for me) still, while compiling pango misses some libpixman symbols, and libpixman seems to be compiled into cairo, you’ll need to download and install libpixman from cairo snapshots separatly and recompile cairo, then add to you LDFLAGS=”-lpixman” otherwise you’ll end with the same result.

    I tried some cairo enabled themes (none complete of course) it looks quite fancy and on my machine i don’t see much speed degradation anyways, however how the hell do i enable Glitz backend!?, i have it compiled support for it on cairo already.

    Anyways, i think it can only be done on source code and not dinamically (depends on the program), they should add something like: GTK_CAIRO_BACKEND, so i can set it to glitz to test ;)

    – Carlos Daniel Ruvalcaba

    • 2005-08-15 12:29 am
      Anonymous

      this is because you use pango-1.9.1 with cairo 0.9.2

      libpixman was moved inside cairo after pango-1.9.1 release and before cairo 0.9.2 release

      so, it is normal. it is already fixed in pango CVS (and 1.10.0)

  • 2005-08-14 8:58 am
    Anonymous

    Baghira theme in KDE gives you a very good OSX look(brushed metal and aqua) and feel. Baghira has been there for a couple of years now. What will be better in the GTKs version of OSX theme?

    • 2005-08-14 5:05 pm
      Anonymous

      Baghira theme in KDE gives you a very good OSX look(brushed metal and aqua) and feel. Baghira has been there for a couple of years now. What will be better in the GTKs version of OSX theme?

      Erm…it’s not ‘GTKs version of’ an ‘OSX theme’. It’s a GTK theme backed by a new rendering engine.

  • 2005-08-14 10:05 am
    superstoned

    na, forget OSX, the new theme you can see some screenshots from on this page are windows vista look-a-likes ;)

  • 2005-08-14 10:36 am
    Felix

    The themes for Gnome are getting better and better especially with cairo what I have seen so far.

    BUT: The stock icons are still the same for a long time. That mustn’t be bad but in my point of view:

    – They look outdated: The colors remind me on old Desktops – too dark, no fresh colors like blue or yellow, very dusky. For example have a look at the default folders in Nautilus which are very dusky

    – Too cluttered: not vectorized, too much details in 16×16 which make them look cluttered. Example: the help icon with the cords

    – They look unsharp, for example the cancel icon

    – They do not harmonize with the new default theme Clearlooks: see http://clearlooks.sourceforge.net/wip/ – look at the first screenshot: compare the cancel button and compare it with the progress bar

    The icons mustn’t be as fanzy as KDE’s Crystal icons but they could look more modern with fresher colors which would be more attractive to new Gnome users and I think especially with Ubuntu there are lots of people who try Linux for the first time.

    I think the stock icons should be replaced by newer ones for example Gorilla SVG, Nuvola, …?

    What do you think?

    • 2005-08-14 10:56 am
      Thom Holwerda

      The problem with using too much color in icons and themes, is that you always wind up with having people who don’t like it, The current defaults in Gnome are sane enough, I think, althought the icons could use an update, but *not* by adding a few colors, and definitely not Gorilla or Nuvola.

      Maybe Suede?

      • 2005-08-14 11:23 am
        Daniel Borgmann

        I have yet to see any icon theme for GNOME that looks as nice and polished as the current set (and this includes Suede). Currently I’m using the gperfection set, which builds on it and AFAIK many items of it are getting merged for 2.12.

        An icon set needs to be complete and actively maintained, so unless Jimmac changes his style or someone else steps up and does a similar magnificiant job, I really don’t think it would be smart to start from scratch with a new style. At the very least, it would have to be a serious and unquestionable improvement.

        Anyway, it’s quite amazing how long I’ve been using the current GNOME icons now and I still love them. ;) Every once in a while I try one of the new shiny icon sets, but always get tired of them very quickly.

        • 2005-08-14 11:26 am
          Thom Holwerda

          Anyway, it’s quite amazing how long I’ve been using the current GNOME icons now and I still love them. ;) Every once in a while I try one of the new shiny icon sets, but always get tired of them very quickly.

          Yeah, I agree. The original icon set is the only really complete one, so I always end up using it too. It might not be as shiny as Crystal, or Apple’s Aqua icons I use on my iBook, but at least it is coherent, and it doesn’t pretend to be anything more than a default icon set.

          • 2005-08-14 3:22 pm
            Felix

            “Yeah, I agree. The original icon set is the only really complete one, …”

            As far as I have seen are Bluecurve icons also very complete. Ok but their from Redhat and I don’t know if they have a special copyright on it.

            “…and it doesn’t pretend to be anything more than a default icon set.”

            Yes but even the default icon set should look good because otherwise it is all on the distributers to ship their versions with better icons.

            This goes in the other direction than Clearlooks which is a great theme which the distributers will adapt so that Gnome will look equal in many distributions which is better for recognition of Gnome for new users.

            If they use different icon sets Gnome looks different everywhere instead having one good icon set which many distributers could use.

          • 2005-08-14 3:41 pm
            Daniel Borgmann

            Hardly anyone uses a different icon set. Red Hat has Bluecurve which isn’t really better and Novell uses the same style, just with some tweaks (as Jimmac works for them).

        • 2005-08-14 3:13 pm
          Felix

          “I have yet to see any icon theme for GNOME that looks as nice and polished as the current set (and this includes Suede). Currently I’m using the gperfection set, which builds on it and AFAIK many items of it are getting merged for 2.12.”

          With Suede I agree with you. They look much better than the current icons because they have brighter, friendlier colors and not so many details which is better if you have small icons like 16×16.

          Too many details look a little bit childish sometimes like the icon with the car for the Gnome configuration editor.

          But as far I have seen the Suede icon set has no stock icons but it would be great to use the other icons of it in the next Gnome release.

      • 2005-08-14 3:28 pm
        Felix

        “The problem with using too much color in icons and themes, is that you always wind up with having people who don’t like it,…”

        Yes, for me Suede is much better as I have written in an upper post but it’s missing stock icons.

        I think in times where we have more than 16 colors desktops can be a little bit more colorful than the default icons are. Which doesn’t imply that using many colors is better.

        Ok, Nuvola is maybe too colorful but Suede could be a good start for a new complete icon set. Especially it consist of SVG icons.

  • 2005-08-14 1:06 pm
    JrezIN

    Cairo is the way to go. It’s something that can abstract the way drawing is done for software, hardware and multiple plataforms… well, it “can” be done, I hope soon! =]

    I’m concerned about the GTK 2.8 for windows. Is there any progress about the conversion? any test versions? Because, today, GTK+ has several performance problems in Windows… Cairo can make it better, or worst… Anyone got some info about it?

    I’m pretty sure Cairo could be accelerated in Windows (not sure if it’s worth before Vista, but anyway…) and also in MacOS X using Quartz. That’ll be great.

    #

    Also, as everything is vector now… is there any documentation/plans about resolution independent interfaces using GTK+ 2.8+ and Cairo? I’m really interested in this subject!

  • 2005-08-14 1:47 pm
    Anonymous

    can I install this without fuck up my current gnome installation?(Gnome 2.10)

    • 2005-08-14 3:16 pm
      segedunum

      can I install this without fuck up my current gnome installation?(Gnome 2.10)

      No.

      • 2005-08-14 6:04 pm
        Anonymous

        can I install this without fuck up my current gnome installation?(Gnome 2.10)

        No.

        Don’t talk crap. GTK maintains ABI in all 2.x releases, you can just drop 2.8 in replacing 2.6 and everything will keep working just fine.

        • 2005-08-14 7:18 pm
          Anonymous

          It was a question

  • 2005-08-14 2:51 pm
    Anonymous

    I use XFCE4 with clearlooks. Clearlooks looks great and has a nice clean feel to it. I didn’t like the color of the titlebars it chose and the highlight color. To change that in XFCE4 I edited /usr/share/themes/Clearlooks/gtk-2.0/gtkrc and changed the hex value of the colors to the ones I wanted. Now the title bar is a nice, rich dark blue making it easy to read.

    I think people have to keep in mind that both mozilla.org and openoffice.org are using Cairo now so the performance issues will get fixed over time. This is exciting news for theme builders. Finally real anti-aliasing for every widget. Should make a very clean UI.

  • 2005-08-14 2:58 pm
    vinterbleg

    I have just emerged it from BreakMyGentoo.

    Everything seems to work fine, except redrawing is painfully slow. Especially in Firefox, it’s actually visible.

    Most problems are temporarily solved using a composite manager, but the very fact that I can use one tells us that GTK+ 2.8 does not yet use glitz (composite+OpenGL crashes in most setups, including mine).

    Cleaklooks-cairo isn’t very complete yet, some widgets are still the Default, but the new progressbars and stuff are nice eye-candy.

    It only gets better from now on. I did try some basic drawing test case operations with Cairo and glitz, and it is blazingly fast. I can’t be anything but enthusiastic about GTK+ getting OpenGL rendering…

    – Simon

  • 2005-08-14 9:11 pm
    Anonymous

    On my Sempron 2200+ (1500 MHz, 1024 MB ram) I have no issues with GTK-2.X. This is true for Windows as well as for Gnome. I haven’t tried using GTK+-apps in KDE, but I wouldn’t be surprised if it gave problems in certain setups. That is to be expected. But in windows I have no problems at all. It works as well (or as bad) as native winforms. But maybe it’s on XP it gives problems?

    /dylansmrjones

    • 2005-08-14 9:30 pm
      J. M.

      Yes, I only tried the Windows version on Windows XP. So I don’t know if it’s specific to Windows XP, but it’s blatently obvious even to a person who otherwise cannot notice any performance problems with anything. Resize a window – an until you stop resizing or release the mouse button, the window contents are frozen, don’t move at all. Only when you stop dragging the window border, the stuff inside the window resizes to the requested size.

      And that’s just resizing. The huge performance difference compared to native Windows GUI is totally obvious, too. I switch tabs from tab1 to tab2 – and see the tab2 widgets being gradually drawn, one by one. Of course it’s still mostly a fraction of a second, I’m not talking about 30s delays or anything like that. But it’s obvious, visible, very noticeable.

      And the Windows version still has exactly the same performance problems that the X (Linux, BSD etc.) version has. Open and close a combo box in the native Windows GUI several times. The CPU meter still shows 0 percent. Just open the combo box once in GTK+ and the CPU meter jumps to several percent. The same with opening a context menu (right-clicking) etc. That’s really typical – it is much more CPU-hungry than the native Windows GUI and it’s often really noticeable. For example the open-save dialog – when you change a directory in the native Windows open/save dialog, it’s instantaneous, absolutely no noticeable delay (must be much less than 0.1 s). With the new GTK+ open/save dialog, there’s always noticeable delay (also when you just open the dialog). The redraw speed in the Windows version of GTK+ is just as bad as it is in X, possibly even worse. Drag windows with native MS Windows GUI around, and you get perfectly smooth redrawing. Move some window over a GTK+ window, and you’ll see the horrible redraw lag. Windows with native MS GUI appear instantaneously, with GTK+ I can often see the contents being gradually drawn to the screen (again, it’s a fraction of a second, but noticeable). And so on.

      The Windows version of GTK+ simply doesn’t feel like native GUI. The lack of speed is especially noticeable there, because the Microsoft Windows GUI is superfast and extremely efficient (i.e. consumes much less CPU cycles for the same tasks). If you dont believe me, just do various things with the GUI with GTK+, Qt and the Windows GUI and watch the CPU monitor. You might be surprised.

      • 2005-08-14 10:25 pm
        Mystilleef

        I use Windows XP with 256MB of RAM powered by a 1.4GHz Athlon XP processor. I’ve used Abiword, Gaim and a number of GTK+ applications on Window, and I am not experiencing any of your problems.

        I do not feel GTK+ is any worse or better than Windows’ native widgets or Qt. I have yet to come accross anybody who complained about GTK+ give concrete, undisputable and objective data regarding it’s slowness.

        The complaints have always been along the line of, “Its faster, than X but it is slower than Y.” If I was a GTK+ developer and you wrote that in a bug report, I would openly insult you.

        Several individuals on this thread alone have provided data that were actually systematically measured. These data showed were GTK excelled and where it had drawbacks. These are useful information developers can use to track down problems and profile.

        Among the “GTK is Slow” clans, none of them have actually sat down to provide any substantial data other than, anecdotal evidence and other questionable subjective experience, not to mention geeky fetishes, like 1% spikes in CPU usage.

        If GTK is really slow, I’d like the GTK is SLOW crowd to actually provide data no matter how unscientific that at least we look at study and make comparisons.

        Oh, by the way, my car is better than yours and it is so blatantly obvious. Just put your car right beside mine and you will see for yourself.

        • 2005-08-14 11:08 pm
          J. M.

          If I see that GTK+ on Windows XP does not react to window resizing at all until you stop resizing the window, I absolutely don’t need any scientific data to be able to say that the window resizing with GTK+ on Windows XP sucks. If I see that a feature that needs 0 % CPU in the Windows GUI needs 30 % CPU for the same task in GTK+, I don’t need any scientific data to be able to say that the iplemenmtation of this task in GTK+ is inefficient. If I see (and yes, I can see it all the time, on different computers) GTK+ gradually drawing individual widgets in the window, one by one when you switch tabs, I absolutely don’t need any scientific data to be able to say that switching tabs in GTK+ is substantially slower than it is elsewhere.

          Is it so hard to understand? This is not some anecdotical evidence, some vague nonsense, without saying anything concrete. This is my real observation, and I’ve been observing this issue *very* carefully (much more carefully than most people here can imagine) and *very* often during the last couple of years. It is real. The fact that I didn’t perform any scientific benchmarks is irrelevant. When the user can see that the GUI is slow, it is slow. Period.

          • 2005-08-14 11:48 pm
            Mystilleef

            How come I’m not seeing this resizing issues on Windows? Do you get my point now? If you see ghosts, and other people don’t see them, they begin to start doubting your judgements.

            In this case, people will just label you a troll, at least until we can all begin to see what you are seeing? Developers will ignore you until you provide data that is useful to them.

            Throwing around inflamatory keywords like “sucks”, “inefficient”, etc., will only frustrate you further. It won’t solve the problem, if indeed there is any.

            What is it so hard to understand? What is hard to understand is that you expect developers to miraculously make GTK+ faster, without providing them with useful/concrete facts.

            That’s like going to the doctor and telling her you are sick but you don’t know the symptoms. How is she gonna treat you?

          • 2005-08-14 11:53 pm
            raylpc

            Good point. J.M. is already in my troll list.

          • 2005-08-15 12:32 am
            Anonymous

            And herein lies the problem. It seems that anyone who reports a problem without this “scientific data” is instantly labeled a troll and discarded, ignored.

            What about an end user with little or no computer experience? They see the problems, they don’t know what’s causing them, they don’t know how to go about collecting this “scientific data”, they simply report what they see and are labeled trolls for doing so and so their data is instantly disregarded. Now how is GTK+ going to improve as a result? It seem that you’re happy to leave gnome/gtk to the power-users. I don’t want that, I love gnome and want to see it emerge as the de facto desktop environment, but instead this level of ignorance and unwillingness drives users away. The casual computer user isn’t the type of person that reads osnews, posts to bugzilla etc. They’ll see the problems, get sick of them, and switch.

            That situation isn’t going to change unless attitudes change within the GTK+ development community.

          • 2005-08-15 12:48 am
            J. M.

            It seems that anyone who reports a problem without this “scientific data” is instantly labeled a troll and discarded, ignored.

            Exactly. There are things that people don’t want to hear. It is natural – when someone likes something or even made that something, it is in the human nature to get annoyed when someone says there’s some particular problem with it.

            It is the equivalent of reporting bugs – normal developers are even glad when a user reports a bug. Because the developer can fix it. The developers don’t ask the user “to provide scientific data & analysis”. That would be ridiculous.

            Again – when a user says that in toolkit XY, drag’n’drop eats 30 % CPU, while in tookit AB it’s only 5 %, this particular, concrete information is enough for the XY developer to look where the problem could possibly be with this particular inefficiency. Or if they’re not interested in finding the cause or don’t have time for it, they say “OK, but I can’t fix it,. feel free to do tit yourself”. But – only if the XY developer is a normal person. In the strange GTK+ camp, user saying this thing is automatically labeled as “troll that doesn’t provide any scientific data, just throwing around inflamatory keywords like ‘inefficient'”. This is not normal.

          • 2005-08-15 1:18 am
            Mystilleef

            Hence, GTK+ developers are abnormal, right?

          • 2005-08-15 1:33 am
            ma_d

            Yes we do. Bug reports that don’t provide instructions on how to reproduce them are usually ignored.

            Users who report what they see are never called trolls. Users who report them in public forums are. Users who report them to someone for the purposes of fixing the bug are not trolls because they intend to help. Users who whine in public forums only intend harm and spreading of their malcontent: No one likes a loud-mouthed malcontent; a troll.

          • 2005-08-15 2:24 am
            Anonymous

            I can confirm the slow resize and redraw issues on Windows XP with the only Gtk app I’m using, SideSMS.

            I’m on a Pentium 4 1.7 w/GeForce4. However, I think the most important issue is look n’feel; even though they’re trying to mimic XP’s theme, gtk apps really look like foreign apps.

          • 2005-08-15 2:59 am
            JLF65

            Again – when a user says that in toolkit XY, drag’n’drop eats 30 % CPU, while in tookit AB it’s only 5 %, this particular, concrete information is enough for the XY developer to look where the problem could possibly be with this particular inefficiency.

            So far that I’ve seen, you’ve been posting about gtk in Windows. First, gtk in Windows is handled at the application level while the Windows GUI is handled at the system level. MS doesn’t want competition from different window managers.

            Second, the Windows version of gtk is not handled by the gtk people. It’s a third party port. Whining on the gtk lists about the performance of gtk for Windows will just get you laughed at.

            As Tor Lillqvist says on his GTk+ and GIMP for Windows Rationale page:

            “Originally (in 1997, I think it was) I started doing the port of GIMP to Windows because my slide scanner (a Minolta Dimâge Scan Dual) isn’t supported by SANE. I am thus forced to use it in Windows.

            “I did look into reverse engineering the protocol to be able to use the scanner under Linux, but that seemed very hard. Thus I had to use it on Windows. And thus I thought that I would like to be able to use the GIMP in Windows, too.

            “I thought, what the heck, let’s try, it might be an interesting intellectual challenge. Maybe I’m a bit perverted, but I actually have enjoyed the porting, even if I do much prefer Unix to Windows.”

          • 2005-08-15 3:07 am
            J. M.

            So far that I’ve seen, you’ve been posting about gtk in Windows.

            The CPU usage with GTK+ is similar in all operating systems I use – Windows XP, Linux and NetBSD.

            But it’s true that the Windows port feels slower in some things than the X version – resizing, switching tabs. But still, these (and some other) things are slower in the X version of GTK+ than it is for example in Qt. So this is not specific to the Windows port.

          • 2005-08-15 4:59 am
            rayiner

            Actually, the Win32 widget set is just a userspace library, like GTK+.

          • 2005-08-15 12:12 am
            Anonymous

            People have reported the symptoms! Windows take noticable time to redraw when you resize them, menus don’t get populated with icons until your mouse is halfway through the third submenu, switching virtual desktops takes too long, etc.

            To stretch your medical analogy a bit further: The gtk developers are a bit like doctors who refuse to even consider treating your disease (slow widget drawing) until you can give them a culture of the bacteria that you’re infected with (repeatable test cases), a complete sequence of it’s DNA (voluminous library profiling), and a finished, FDA-approved drug to treat it (patch that will meet with all gtk developers’ approval with no further work).

          • 2005-08-15 12:45 am
            Mystilleef

            How come you and J.M are the only folks witnessing these slow drawings?

          • 2005-08-15 12:26 am
            J. M.

            Throwing around inflamatory keywords like “sucks”, “inefficient”, etc., will only frustrate you further.

            Since when is “inefficient” an inflamatory keyword? And I actually explained in that sentence why the word “sucks” is not inflamatory there either, but a fair description. Please read the whole sentence.

            What is hard to understand is that you expect developers to miraculously make GTK+ faster, without providing them with useful/concrete facts.

            I already provided many concrete facts. You just automatically dismissed them. And I never said that I expect the GTK+ developers to miraculously make it faster. This is the attitude problem I was talking about earlier – you, just like the GTK+ people, have problem admitting that there could be something wrong with the toolkit you like. When people say it’s slow, you say that they don’t say anything concrete. When they say something concrete, you say that it doesn’t matter. When you explain why it matters, you say “provide scientific data and send a patch”. When people send patches, they refuse them. Until this attitude in the GTK+ camp changes, things will never change to better.

          • 2005-08-15 4:37 pm
            Anonymous

            Where is the time being taken?

            What functions?

            What widgets were in the windows?

            What containers were they packed in?

            Can you provide a small test program to demo?

            How about a video-screenshot?

            Maybe a profiler log?

            Right now, you’ve told us absolutely nothing, except that you see a problem nobody else seems to.

          • 2005-08-15 6:05 pm
            Wrawrat

            That’s like going to the doctor and telling her you are sick but you don’t know the symptoms. How is she gonna treat you?

            Actually, it’s more like you are telling your symptoms to a physician, but he/she dismisses you as an hypochondriac because you can’t name your illness. Knowing the name and even the cure would help him/her tremedously, but that’s not how daily life works.

            There is no need in being so defensive. We are not getting personal with you. We are sharing our perception. GTK might be fast on benchmarks, but it still feels slow to many of us. Personally, it doesn’t feel snappy on my fairly recent machines (2x XP2500+, Centrino 1.7) with four different OSes (Windows XP, Debian, Ubuntu, Gentoo). Response time is alright, but redraw is sluggish. It’s mostly noticeable in XP, but I can understand it’s the least of their worries.

            Now, I admit my experience is not easily benchmarkable and it’s fairly difficult to pinpoint the exact cause to developers. I don’t have the knowledge to profile the toolkit nor have the time to learn about it. Still, does that make me a troll or a liar? Does that make my opinion completely irrelevant? I happen to be a programmer, but millions of people are not.

            Last, but not the least: it’s not because you can’t notice it that it doesn’t exist.

          • 2005-08-15 1:35 am
            ma_d

            Everything you stated is scientific data. I think what you don’t need is analist data.

  • 2005-08-14 11:29 pm
    Anonymous

    It seems most of those complaining about gtk are using it in kde.

    kde uses a different toolkit, and two toolkits are in use, slowing down performance.

    Try using a kde/qt app in gnome, and you will notice the same problems.

    when comparing performance, please use gtk apps in a gtk environment, and qt apps in a qt environment to compare.

    In an ideal world the performance would be equally good in each other environments, bu hey in such an environment MS would also be an oss company!

    There are a few issues with gtk on windows, but the major one is not flicker etc (I have not noticed any on my p3667mhz), but the non-native look.

  • 2005-08-14 11:46 pm
    Best

    Slackware’s default gnome is highly unoptimized and has had very little attention paid to it making it a poor representation in general. If good performance in gnome is a primary concern I would recomend dropline, or if ‘purity’ is a concern, any of the other gnome distros outside of the mainline slackware.

  • 2005-08-15 12:29 am
    Anonymous

    “People have reported the symptoms!”

    and alot of people still dosent have those sympthoms.

    i only notice the resising issue on my p3 866 laptop with a crappy integrated gfx card

    “menus don’t get populated with icons until your mouse is halfway through the third submenu, switching virtual desktops takes too long”

    that i have never seen and on my workstation wich isnt like 5 years old i dont notice any resising issues.

  • 2005-08-15 12:30 am
    Anonymous

    I’ve noted too that problem when I reside a GTK Window on Windows, but hey, that won’t make stop using GIMP at all because it rocks, slow redraw in a window is something I can live with, the same with GNOME, slow repaint? I don’t even note it anymore, the plus are more than the cons, Im happy with it and I accep it like it is, it is free and rocks.

  • 2005-08-15 12:41 am
    Anonymous

    And herein lies the problem. It seems that anyone who reports a problem without this “scientific data” is instantly labeled a troll and discarded, ignored.

    you are rigth, the problem is there, but you must acept that is only about apretiation, if a window redraw takes 0.5 seconds more of waht it should is not the end of the world and not for that deprecate GTK as slow, is fast enough and can do the work fine.

    Avery new version of GTK is faster, its getting there, have a litle patient.

  • 2005-08-15 12:46 am
    Anonymous

    Take the latest version of Gaim (1.5.0), Inkscape (0.42) and the latest version of Gtk+ binaries for Win32(2.6.9a). Open the Gaim “login” window and an empty Inkscape window.

    My machine is Athlon 850, 640M of memory, running WinXP Sp2. At the start of the experiment, ~200M of memory is used, and background CPU usage is below 3%.

    On my machine, after I drag one of these windows over the other, the bottom window takes ~0.5 seconds to redraw; this is reproducible. If I drag two native win32 windows over each other, the redraw is so fast that I can’t see it.

    As for CPU usage: dragging native win32 windows over each other pushes CPU usage to ~30% while the windows are moving. Dragging gtk windows over each other pushes CPU usage to ~50-60% while the windows are moving.

    Very similar results are obtained with any gtk+ app on Windows that I’ve tried (i.e. Ethereal, Gimp, Inkscape, and Freeciv). And if two windows belonging to the same process (e.g. two Gaim windows) are dragged over each other, the redraw time gets even worse: as much as 1 second.

    All of these results are completely reproducible.

    Conclusion: gtk+ on Windows on low-end machines is SLOW.

  • 2005-08-15 1:39 am
    Anonymous

    So I assume all of you who are experiencing these problems have reported them?

    Its no use bitching over here.

    If there are any problems (which there are, but I do not see the ones reported here), make your bug reports.

    Let the dev’s know of the problem.

    I have just tried draggind gaim over inkscape. I also tried dragging firefox over IE, gaim over firefox, inkscape over ie… the redraws are pretty similar on my measley p3 667.

  • 2005-08-15 2:28 am
    Anonymous

    gtk apps really look like foreign apps.

    Try the newest libwimp, it has my improvements

    check this:

    http://gtk-wimp.sourceforge.net/screenshots/

  • 2005-08-15 2:30 am
    Anonymous

    it has my improvements

    *many improvements.

    • 2005-08-15 3:01 pm
      Sphinx

      For all you know those are his improvements which would turn your answer from just plain smartass into really stupid.

      • 2005-08-16 6:08 am
        Anonymous

        Looks more like he was correcting himself. And he is the stupid one? ROFL.

  • 2005-08-15 7:14 am
    Anonymous

    Someone please point me to the Windows installer for GGTK+ 2.8. Thank you~!

    • 2005-08-15 1:37 pm
      JrezIN

      I’m afraid there’s no GTK+ version 2.7.x or 2.8.x available to win32 yet. The official download site for GTK and GIMP for windows is:

      http://gimp-win.sourceforge.net/stable.html

      The latest version available there is 2.6.8.

      (someone, please, correct me if I’m wrong!)

  • 2005-08-15 10:22 am
    kmaraas

    People complaining about these when running under metacity will probably want to check out the ‘reduced_resources’ gconf key for metacity and turn that on.

    • 2005-08-15 11:09 am
      Anonymous

      Unfortunately the ‘reduced_resources’ mode is broken for ages. Turn it on, try to maximize some windows by double clicking the window bar and see what happens.

      In addition, the ‘reduced_resources’-mode looks awfully due to the far too thick black lines that are drawn when you resize a window.

  • 2005-08-15 5:05 pm
    JeffS

    To those saying GTK+ is slow, please try Xfce4.x. Xfce uses GTK+ and it’s super fast.

    To those saying GTK+ apps run slower when launched in KDE, please try running QT/KDE apps in Gnome – you get the same result. When I run KDE apps in Gnome, they are much slower than when running them in KDE.

    To those saying GTK+/Gnome are slow in a particular non-gnome-optimized distro (like Slackware), please try using Ubuntu, Fedora, or pure Debian (to name 3). In my experience, Gnome/GTK is lickity split fast in those distros, and typically as fast or faster than KDE/QT. But it’s a bit slower in KDE default distros like Mandrake or SuSE. In other words, distros do implement optimizations on the DE that they default to, and don’t optimize the DE that is not the default.

    Finally, the performance I get out of GTK+ and Gnome in distros that do default to, or optimize, Gnome/GTK, is excellent. I’m running pure Debian on a 300Mhz pentium II, with 228 megs ram Thinkpad 600 (really legacy, slow hardware), and Gnome/GTK+ stuff is very snappy. Now, if I chose a heavier theme (like “Nuvola”), it will slow down a bit. But if I stick with a lighter theme, like “Simple” or “Mist” (both are very attractive, IMHO), I get lickity-split performance.

    Also, I’ve run Abiword on Windows, and it’s performance was great – no redraw problems or slowdowns.

    And I already mentioned that Xfce is fast. It’s worth mentioning again. Xfce is fast, very fast, and very light on computer resources. And guess what? Xfce uses GTK+. And Xfce has become very full featured, and has great looking themes.

    So the so called performance problems with GTK+ and Gnome are more often a matter of perception and/or implementation, or simply using really bad, illogical tests (like saying GTK apps run slower in KDE – well duh).

    • 2005-08-16 3:30 pm
      Hugo

      “Also, I’ve run Abiword on Windows, and it’s performance was great – no redraw problems or slowdowns.”

      Abiword on windows doesn’t use GTK.

  • 2005-08-15 5:44 pm
    Anonymous

    Today I tried to run GTK and Qt applications through X-forwarding via ssh over a 100Mbit line on an iBook G3 800Mhz with an ATI Radeon Mobility chip from a Red Hat Enterprise 3 machine with a P4 2.4 GHz.

    This adds a little bit of latency and overhead and the speed problems should be a lot more visible.

    I ran gedit, kedit and emacs:

    gedit, kedit and emacs all showed the menus instantanous (could not measure any wait). kedit however, showed flicker while doing it, while gedit and emacs showed no such thing.

    gedit and kedit both both showed equal amount of redraw when resizing window. Not as much as to hinder any work or productivity. Emacs felt a little worse.

    kedit opened the preference window a tiny bit faster than gedit.

    I also tried GGV with a few postscript files, with good results.

    I have yet to use any machine in which GTK shows significant lag. Even my iBook G3 with the Ubuntu LiveCD shows no significant lag, apart from when it is reading from the CD.

    This leads me to conclude that the outcry about GTK slowness is either:

    a) Limited to a certain type of hardware with particularly bad X-drivers or X-drivers that highlight weaknesses in GTK or drivers that are bad at things GTK use a lot of.

    b) A myth, possible being put forward dishonestly.

  • 2005-08-15 7:10 pm
    Anonymous

    X drivers for i8xx (845g,855g, etc) are slow. i get much more response on drivers for ati.

  • 2005-08-16 8:15 am
    Anonymous

    And what will now be in gtk 2.10. What is planned next ?

  • 2005-08-16 10:40 am
    Anonymous

    While I love the API (it’s a thousand times better than the proprietary Microseft Windows XP piece of shit Win32 API) I’ve been very disappointed with the speed in the 2.x series. Hopefully Cairo + Glitz will eventually solve that.