Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
Hey, This thread has just petered out, but Alex still needs an answer. On Fri, 2005-06-10 at 14:59 +0200, Alexander Larsson wrote: On Wed, 2005-06-08 at 15:53 +0200, Alexander Larsson wrote: On Wed, 2005-06-08 at 13:50 +0100, Mark McLoughlin wrote: - The benefit of being able to use all the other new APIs in GTK+ 2.8 for GNOME 2.12 This was the reason i brought up this with jamesh, leading to the change of the jhbuild modules. In particular, I'd like to use the new g_utf8_collate_key_for_filename() function from glib in nautilus. Technically I guess we could make a copy of this function in nautilus for now, but it would be nice to be able to use the glib code, and to have the same sort in the file selector. Is it ok if nautilus depends on glib 2.8 for this? This doesn't mean we have to use gtk+ 2.8, gtk+ 2.6 works fine with glib 2.8. Its a bit strange as glib and gtk+ have historically released very much in lockstep. However, nothing says this is needed. Opinions? Personally, I don't see why not. I mean the GTK+/glib maintainers have a schedule that suits GNOME 2.8 fine ... it seems like we're only holding back from depending on GTK+ 2.8 because of stability worries. Those worries don't apply to glib ... Cheers, Mark. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
Le jeudi 16 juin 2005 16:13 +0100, Mark McLoughlin a crit : Is it ok if nautilus depends on glib 2.8 for this? This doesn't mean we have to use gtk+ 2.8, gtk+ 2.6 works fine with glib 2.8. Its a bit strange as glib and gtk+ have historically released very much in lockstep. However, nothing says this is needed. Opinions? Personally, I don't see why not. I mean the GTK+/glib maintainers have a schedule that suits GNOME 2.8 fine ... it seems like we're only holding back from depending on GTK+ 2.8 because of stability worries. Those worries don't apply to glib ... I agree. Depending on glib 2.8 seems okay to me. Vincent -- Les gens heureux ne sont pas presss. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On Fri, 2005-06-10 at 09:33 -0400, Owen Taylor wrote: On Fri, 2005-06-10 at 15:12 +0200, Jeroen Zwartepoorte wrote: Since everybody is talking about how glitz will eventually speedup drawing operations by using hardware accelerated OpenGL, i built it and then rebuilt cairo so cairo will detect glitz and compile with support for it. How does glitz further integrate into the desktop stack? Can i make gtk+ use glitz for drawing widgets? If so, how? The way glitz integrates in is on the server side: GTK+ = Cairo --- RENDER --- X server = glitz = OpenGL This will give the same basic performance benefits as having Cairo use glitz directly, but with many less complications. Currently, we don't foresee having GTK+ render via glitz as a very interesting way to go for the desktop. Note that the performance slowdowns people have been seeing for GtkTextView likely have not much to do with rendering and everything to do with text measurement. You'll have to excude me for not having followed much cairo/X work for a while, but does that ' --- RENDER ---' imply that cairo is rendering lots of traps using the RENDER extension? Thanks, Rob Taylor ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
Le vendredi 10 juin 2005 à 13:10 -0400, Luis Villa a écrit : Each of the major distributors could (should?) package 2.7.0 I've put .deb packages (i386) of the current pango/gtk CVS for Ubuntu here: deb http://people.ubuntu.com/~seb128/gtk ./ Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On 6/14/05, Vincent Untz [EMAIL PROTECTED] wrote: Le mardi 14 juin 2005 à 11:57 +0200, Sebastien Bacher a écrit : Le vendredi 10 juin 2005 à 13:10 -0400, Luis Villa a écrit : Each of the major distributors could (should?) package 2.7.0 I've put .deb packages (i386) of the current pango/gtk CVS for Ubuntu here: deb http://people.ubuntu.com/~seb128/gtk ./ Fantastic! Do you think that asking breezy users to try it on the Ubuntu forums and/or mailing lists is appropriate? Might be worth waiting for http://bugzilla.gnome.org/show_bug.cgi?id=306216 to be fixed before pimping it too widely? Luis (using it now) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
For non-local servers without Render, Cairo will allow us to eliminate the round-trips... a huge win. Show me the money! Back in the real world, new code goes in and someone files a performance bug. Then you, Owen, seem to take that as a personal insult and close it as NOTABUG or WONTFIX. Exhibit 1: bug 94718. A clear, to-the-point bug report that something (namely greying of toolbars) had gotten so much slower that it was a problem. It still is. Exhibit 2: bug 123538. Pango/GtkTreeview gets very slow with lots of data, a situation that less handled well a decade or two ago. I routinely use less on files larger than 1GB or with lines that are thousands of characters wide. While you didn't actually close this bug (we kept it under Gnumeric) you seem to think I am outside what you designed for, hence my Hello World poke. Exhibit 3: bug 104683. General Pango performance with a patch that at the time cut 70% of cpu usage for the all-ASCII case (such as numbers) that Gnumeric uses heavily. You NOTABUG'd it *twice* (and futured it once) as evidently Pango's performance cannot possibly be problematic. I am somehow reminded of the word attitude reading these old, but still-open, bug reports. Rendering speed is 90% an X server issue. I would normally define rendering speed as a measure of how fast you get your pixels on the screen. With that definition in mind, look at bugs 94718 and 104683 above and see that getting pixels on the screen got much slower with constant X server. The toolkit is much, much more than 10%. We love you too, Morten. I am all cuddly. (Think Jack-Jack from a certain, recent animated movie.) M. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
quote who=Morten Welinder For non-local servers without Render, Cairo will allow us to eliminate the round-trips... a huge win. Show me the money! Morten, I can understand your frustration, but to abuse some more movie quotes: Your tone was pretty bogus, and we should all be excellent to each other, regardless of any day-to-day hacking gripes we may have. I've always found that positive reinforcement and encouragement goes a lot further than snide remarks (having tried both!), and it's our positivity that will bring new developers into - and hopefully stay in - our community. Thanks, - Jeff -- OSCON 2005: August 1st-5th http://conferences.oreillynet.com/os2005/ It's never been, 'We're doing this for the good of society.' It's always been us taking an intellectual pride in putting out a good product - and making money. If putting a computer on every desktop and in every home didn't make money, we wouldn't do it. - Microserfs ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On Sun, 2005-06-12 at 22:53 -0400, Morten Welinder wrote: For non-local servers without Render, Cairo will allow us to eliminate the round-trips... a huge win. Show me the money! Back in the real world, new code goes in and someone files a performance bug. Then you, Owen, seem to take that as a personal insult and close it as NOTABUG or WONTFIX. Exhibit 1: bug 94718. A clear, to-the-point bug report that something (namely greying of toolbars) had gotten so much slower that it was a problem. It still is. The bug was originally filed in useless form, I indicated as much. when it was reopened with more useful data, it was left open. The data in the bug report is still really not very good ... all the profiling data was done in the remote case, and may well be completely irrelevant if the actual time is spent in roundtrips to the server (I think it is). But with the test case, there's the possibility that someone could pick up the bug, get some better data and come up with a patch. Exhibit 2: bug 123538. Pango/GtkTreeview gets very slow with lots of data, a situation that less handled well a decade or two ago. I routinely use less on files larger than 1GB or with lines that are thousands of characters wide. While you didn't actually close this bug (we kept it under Gnumeric) you seem to think I am outside what you designed for, hence my Hello World poke. You clear have *no* idea what I'm saying in comment #7. Or you'd realize that looking at the performance of 'less' is completely irrelevant here. Fixed with character grids without complex text handling are inherently fast. That doesn't mean that it's easy to make GtkTextView just as fast on the same font and data. Exhibit 3: bug 104683. General Pango performance with a patch that at the time cut 70% of cpu usage for the all-ASCII case (such as numbers) that Gnumeric uses heavily. You NOTABUG'd it *twice* (and futured it once) as evidently Pango's performance cannot possibly be problematic. Problems with this patch: - The 70% timing was done with code paths that weren't used by almost anybody when you filed the bug report, and aren't even minimally supported today - The patch made assumptions [width(AB) = width(A) + width(B)] that were planned to be broken at the point you filed the bug report and have since been broken. - The patch was lots of completely unrelated things shuffled together, many without any real justification In terms of NOTABUG, that's clearly explained in the comments in bug report. When you analyze the bug report, it comes down Pango is slower than Morten likes. It's slower than Owen likes as well. Having a bug open like that does nothing to make Pango better. I want bug reports to be specific to particular issues. I left it open eventually because I got tired of fighting the battle. I am somehow reminded of the word attitude reading these old, but still-open, bug reports. What I try to make very clear on performance bug reports is that: A) Reports of something being *slower* than some previous version of GTK+ is not, in itself an issue. Things get slower typically because we add interesting and important features. Something being slower is *only* a problem when it is a performance bottleneck. B) Bug reports should be about specific fixable items. A bug report complaining that Pango is slow is not specific enough to be useful. C) Random patches that optimize some function that doesn't show up on profiles and without any benchmark to show that that patch makes a difference will not be accepted. It is in fact pretty hard to get me to take a performance patch for Pango. This is not because I don't want to improve Pango performance, it's because I've spent weeks and months working on Pango performance, so if a patch was easy to come up with, it's most likely either close to irrelevant or incorrect. There certainly are some areas where things could be improved (and some patches in Bugzilla to do so, especially for Arabic/Indic shaping), but we're talking mostly a few percent speedups. With a well-written ASCII-only codepath and programmatic options to degrade layout quality for speed, you might manage to get a 50% speedup for text *layout*. But Gnumeric cares most about text *rendering* speed, and with the X servers most people are running currently, speeding up text *layout* 50% will speed up rendering maybe 10%. Rendering speed is 90% an X server issue. I would normally define rendering speed as a measure of how fast you get your pixels on the screen. With that definition in mind, look at bugs 94718 and 104683 above and see that getting pixels on the screen got much slower with constant X server. The toolkit is much, much more than 10%. Rendering *DIFFERENT THINGS*. Yes, rendering alpha-composited images on a remote sever without the RENDER extension is slow. Duh. Cairo, as I noted above, would allow someone
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
Since everybody is talking about how glitz will eventually speedup drawing operations by using hardware accelerated OpenGL, i built it and then rebuilt cairo so cairo will detect glitz and compile with support for it. How does glitz further integrate into the desktop stack? Can i make gtk+ use glitz for drawing widgets? If so, how? Regards, Jeroen On 6/10/05, Owen Taylor [EMAIL PROTECTED] wrote: On Thu, 2005-06-09 at 10:49 -0400, Luis Villa wrote: On 6/9/05, Luis Villa [EMAIL PROTECTED] wrote: Went ahead and did it myself. TextView is brutally slower (300-400%), some other things are 25-30% slower, and some things actually get faster. Disclaimer: I'm pretty sure I did this right and I'm linking against the right stuff, but these numbers should be confirmed by an expert, and I can't speak to the validity of the tool's measurements itself, except to note that scrolling in a textview area is *visibly* slower. The data: first 'column' of times is gtk 2.6, second is gtk/cairo HEAD of yesterday, both with the Mist theme: With the Mist theme, you are testing mixed Cairo and GDK rendering. Right now, that could conceivably hide some performance problems with Cairo. In the future, there are some performance optimizations that will be disabled when you are mixing Cairo and GDK rendering. The GTK+ builtin theme probably gives more of an accurate feel for GTK+/Cairo performance. What the appropriate theme to test is does depend on what we will be shipping for GNOME-2.10 as the default, of course. Which is likely not the GTK+ builtin theme. GtkEntry - time: 0.43 0.76 GtkComboBox - time: 12.61 15.30 GtkComboBoxEntry - time: 11.95 13.25 GtkSpinButton - time: 0.65 1.09 GtkProgressBar - time: 0.53 0.87 GtkToggleButton - time: 2.17 4.42 GtkCheckButton - time: 3.41 3.27 GtkRadioButton - time: 4.29 3.96 GtkTextView - Add text - time: 91.88 268.67 GtkTextView - Scroll - time: 43.17 190.83 GtkDrawingArea - Lines - time: 8.40 8.48 GtkDrawingArea - Circles - time: 13.38 13.58 GtkDrawingArea - Text - time: 48.70 29.99 GtkDrawingArea - Pixbufs - time: 11.71 11.46 Without studying what these benchmarks are actually doing, I'd consider them pretty encouraging ... some operations got faster, and what got slower is something we have in our sights already ... cairo_scaled_font_glyph_extents(). (GtkTextView performance is text measuring performance.) There is an obvious big-hammer approach that would allow us to get rid of that ... to put a cache in front of it so that we avoid calling into Cairo entirely, but I'd like to see what we can do inside of Cairo first. Regards, Owen BodyID:12373415.2.n.logpart (stored separately) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On 6/9/05, Luis Villa [EMAIL PROTECTED] wrote: On 6/9/05, Luis Villa [EMAIL PROTECTED] wrote: On 6/9/05, Jon K Hellan [EMAIL PROTECTED] wrote: On Thu, 2005-06-09 at 14:39 +0100, Mark McLoughlin wrote: If we're talking about performance/stability in the context of whether GNOME 2.12 should use GTK+ 2.8, we're effectively saying I think the GTK+ team might ship a unstable or unacceptably slow 2.8.0 release; GNOME shouldn't commit to using GTK+ 2.8 yet. I would hope that we would have more confidence in the judgement of the GTK+ team than that. Crashes and performance are very different types of problem. Crashes get fixed once they can be reproduced. Fixing bad performance can take a long time. Well, I haven't tested gtk2.7 since just after Cairo got added, so I can't tell whether there is a performance problem. Has anybody got numbers? I haven't seen this announced on gtk-devel or here, so: http://gtkperf.sourceforge.net/ Apparently this is a test tool to test gtk performance. Would be great to have someone test 2.7 with it. Went ahead and did it myself. TextView is brutally slower (300-400%), some other things are 25-30% slower, and some things actually get faster. Disclaimer: I'm pretty sure I did this right and I'm linking against the right stuff, but these numbers should be confirmed by an expert, and I can't speak to the validity of the tool's measurements itself, except to note that scrolling in a textview area is *visibly* slower. New third column is HEAD + glitz, with an x31's ATI card. Still with Mist. Performance is slightly slower than HEAD just about everywhere, actually. I'll probably do an N=100 run with default theme + 2.6/HEAD/HEAD + glitz sometime later. Have to figure out how to automate this. :) The data: GtkEntry - time: 0.43 0.76 0.89 GtkComboBox - time: 12.61 15.30 15.11 GtkComboBoxEntry - time: 11.95 13.25 13.36 GtkSpinButton - time: 0.65 1.09 1.17 GtkProgressBar - time: 0.53 0.87 0.99 GtkToggleButton - time: 2.17 4.42 4.47 GtkCheckButton - time: 3.41 3.27 3.37 GtkRadioButton - time: 4.29 3.96 4.10 GtkTextView - Add text - time: 91.88 268.67 311.53 GtkTextView - Scroll - time: 43.17 190.83 229.29 GtkDrawingArea - Lines - time: 8.40 8.48 8.39 GtkDrawingArea - Circles - time: 13.38 13.58 13.42 GtkDrawingArea - Text - time: 48.70 29.99 30.34 GtkDrawingArea - Pixbufs - time: 11.71 11.46 11.16 --- Total time: 253.31 565.94 647.60 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On Fri, 2005-06-10 at 09:21 -0400, Luis Villa wrote: On 6/9/05, Luis Villa [EMAIL PROTECTED] wrote: On 6/9/05, Luis Villa [EMAIL PROTECTED] wrote: On 6/9/05, Jon K Hellan [EMAIL PROTECTED] wrote: On Thu, 2005-06-09 at 14:39 +0100, Mark McLoughlin wrote: If we're talking about performance/stability in the context of whether GNOME 2.12 should use GTK+ 2.8, we're effectively saying I think the GTK+ team might ship a unstable or unacceptably slow 2.8.0 release; GNOME shouldn't commit to using GTK+ 2.8 yet. I would hope that we would have more confidence in the judgement of the GTK+ team than that. Crashes and performance are very different types of problem. Crashes get fixed once they can be reproduced. Fixing bad performance can take a long time. Well, I haven't tested gtk2.7 since just after Cairo got added, so I can't tell whether there is a performance problem. Has anybody got numbers? I haven't seen this announced on gtk-devel or here, so: http://gtkperf.sourceforge.net/ Apparently this is a test tool to test gtk performance. Would be great to have someone test 2.7 with it. Went ahead and did it myself. TextView is brutally slower (300-400%), some other things are 25-30% slower, and some things actually get faster. Disclaimer: I'm pretty sure I did this right and I'm linking against the right stuff, but these numbers should be confirmed by an expert, and I can't speak to the validity of the tool's measurements itself, except to note that scrolling in a textview area is *visibly* slower. New third column is HEAD + glitz, with an x31's ATI card. Still with Mist. Performance is slightly slower than HEAD just about everywhere, actually. I'll probably do an N=100 run with default theme + 2.6/HEAD/HEAD + glitz sometime later. Have to figure out how to automate this. :) I didn't know you could even use glitz with gtk+ HEAD? I asked owen, and he didn't think it worked atm. How did you run this? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a suicidal drug-addicted ex-con fleeing from a secret government programme. She's a sarcastic insomniac mechanic trying to make a difference in a man's world. They fight crime! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On 6/10/05, Luis Villa [EMAIL PROTECTED] wrote: I haven't seen this announced on gtk-devel or here, so: http://gtkperf.sourceforge.net/ Apparently this is a test tool to test gtk performance. Would be great to have someone test 2.7 with it. Went ahead and did it myself. TextView is brutally slower (300-400%), some other things are 25-30% slower, and some things actually get faster. Disclaimer: I'm pretty sure I did this right and I'm linking against the right stuff, but these numbers should be confirmed by an expert, and I can't speak to the validity of the tool's measurements itself, except to note that scrolling in a textview area is *visibly* slower. New third column is HEAD + glitz, with an x31's ATI card. Someone larted me on IRC and informed me that it is likely that glitz wasn't actually being used. So take these with an even bigger grain of salt than my last set. I would love to know how one can (1) know for certain glitz is being used and/or (2) how to force glitz to be used so that I can do a quickie hack to automate this. Still with Mist. Performance is slightly slower than HEAD just about everywhere, actually. I'll probably do an N=100 run with default theme + 2.6/HEAD/HEAD + glitz sometime later. Have to figure out how to automate this. :) The data: GtkEntry - time: 0.43 0.76 0.89 GtkComboBox - time: 12.61 15.30 15.11 GtkComboBoxEntry - time: 11.95 13.25 13.36 GtkSpinButton - time: 0.65 1.09 1.17 GtkProgressBar - time: 0.53 0.87 0.99 GtkToggleButton - time: 2.17 4.42 4.47 GtkCheckButton - time: 3.41 3.27 3.37 GtkRadioButton - time: 4.29 3.96 4.10 GtkTextView - Add text - time: 91.88 268.67 311.53 GtkTextView - Scroll - time: 43.17 190.83 229.29 GtkDrawingArea - Lines - time: 8.40 8.48 8.39 GtkDrawingArea - Circles - time: 13.38 13.58 13.42 GtkDrawingArea - Text - time: 48.70 29.99 30.34 GtkDrawingArea - Pixbufs - time: 11.71 11.46 11.16 --- Total time: 253.31 565.94 647.60 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On 6/10/05, Alexander Larsson [EMAIL PROTECTED] wrote: On Fri, 2005-06-10 at 09:40 -0400, Luis Villa wrote: On 6/10/05, Luis Villa [EMAIL PROTECTED] wrote: I haven't seen this announced on gtk-devel or here, so: http://gtkperf.sourceforge.net/ Apparently this is a test tool to test gtk performance. Would be great to have someone test 2.7 with it. Went ahead and did it myself. TextView is brutally slower (300-400%), some other things are 25-30% slower, and some things actually get faster. Disclaimer: I'm pretty sure I did this right and I'm linking against the right stuff, but these numbers should be confirmed by an expert, and I can't speak to the validity of the tool's measurements itself, except to note that scrolling in a textview area is *visibly* slower. New third column is HEAD + glitz, with an x31's ATI card. Someone larted me on IRC and informed me that it is likely that glitz wasn't actually being used. So take these with an even bigger grain of salt than my last set. I would love to know how one can (1) know for certain glitz is being used and/or (2) how to force glitz to be used so that I can do a quickie hack to automate this. Total time: 253.31 565.94 647.60 The question is: Why did you get different times then? Very good question. I tried to kill anything particularly CPU-consuming, and in all cases stopped using the machine during the test, so I don't *think* that is a factor, but it could have been- it's not like I was running this on a perfectly-controlled test box. (Which I'd like to do, as part of the tinderboxing, whenever someone gets me a box to tinder on :) Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On Fri, 2005-06-10 at 15:12 +0200, Jeroen Zwartepoorte wrote: Since everybody is talking about how glitz will eventually speedup drawing operations by using hardware accelerated OpenGL, i built it and then rebuilt cairo so cairo will detect glitz and compile with support for it. How does glitz further integrate into the desktop stack? Can i make gtk+ use glitz for drawing widgets? If so, how? The way glitz integrates in is on the server side: GTK+ = Cairo --- RENDER --- X server = glitz = OpenGL This will give the same basic performance benefits as having Cairo use glitz directly, but with many less complications. Currently, we don't foresee having GTK+ render via glitz as a very interesting way to go for the desktop. Note that the performance slowdowns people have been seeing for GtkTextView likely have not much to do with rendering and everything to do with text measurement. Regards, Owen signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On Fri, 2005-06-10 at 14:47 +0100, Mark McLoughlin wrote: On Thu, 2005-06-09 at 19:00 -0400, Owen Taylor wrote: - To be realistic, if GNOME-2.12 is released after GTK+-2.8, most distributors are going to ship using them together. So, the release team could decide to go with 2.6 even with the current GTK+ schedule, but the result then would be less testing of what people actually ship. Yeah, and that would significantly undermine the whole release process IMHO. If the value of having GNOME releases is to have the very latest GNOME technologies released as a stable, coherent and integrated set, then by creating a situation where distributors go off for themselves and figure out what *really* is the latest stable set of GNOME technologies, we really reduce the relevance of GNOME releases. Well there are GNOME hackers working at all the major distributors who I am sure are able to inform the rest of their organization that going with GTK 2.8 would greatly increase the risk of bug and problems since it is not what the community have developed and tested with. If we believe that we can't influence the distributions on what they ship anyway, then maybe our whole release process is to be considered useless. I mean what is the point of doing GNOME releases if we assume nobody cares about how we compose our releases anyway. Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On Fri, 2005-06-10 at 09:47 -0400, Luis Villa wrote: On 6/10/05, Alexander Larsson [EMAIL PROTECTED] wrote: On Fri, 2005-06-10 at 09:40 -0400, Luis Villa wrote: On 6/10/05, Luis Villa [EMAIL PROTECTED] wrote: I haven't seen this announced on gtk-devel or here, so: http://gtkperf.sourceforge.net/ Apparently this is a test tool to test gtk performance. Would be great to have someone test 2.7 with it. Went ahead and did it myself. TextView is brutally slower (300-400%), some other things are 25-30% slower, and some things actually get faster. Disclaimer: I'm pretty sure I did this right and I'm linking against the right stuff, but these numbers should be confirmed by an expert, and I can't speak to the validity of the tool's measurements itself, except to note that scrolling in a textview area is *visibly* slower. New third column is HEAD + glitz, with an x31's ATI card. Someone larted me on IRC and informed me that it is likely that glitz wasn't actually being used. So take these with an even bigger grain of salt than my last set. I would love to know how one can (1) know for certain glitz is being used and/or (2) how to force glitz to be used so that I can do a quickie hack to automate this. Total time: 253.31 565.94 647.60 The question is: Why did you get different times then? Very good question. I tried to kill anything particularly CPU-consuming, and in all cases stopped using the machine during the test, so I don't *think* that is a factor, but it could have been- it's not like I was running this on a perfectly-controlled test box. (Which I'd like to do, as part of the tinderboxing, whenever someone gets me a box to tinder on :) I suspect that it's just difficulties in the benchmark ... especially with GtkTextView, things can happen a little differently each time you run it ... a different balance between repainting the screen and updating the text. Everything other than GtkTextView looked the same up to noise, but the GtkTextView numbers dominate the total. Regards, Owen signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On 6/10/05, Mark McLoughlin [EMAIL PROTECTED] wrote: On Thu, 2005-06-09 at 19:00 -0400, Owen Taylor wrote: - To be realistic, if GNOME-2.12 is released after GTK+-2.8, most distributors are going to ship using them together. So, the release team could decide to go with 2.6 even with the current GTK+ schedule, but the result then would be less testing of what people actually ship. Yeah, and that would significantly undermine the whole release process IMHO. If the value of having GNOME releases is to have the very latest GNOME technologies released as a stable, coherent and integrated set, then by creating a situation where distributors go off for themselves and figure out what *really* is the latest stable set of GNOME technologies, we really reduce the relevance of GNOME releases. I'm all in favor of getting 2.7 tested and released, and I think we should push hard to test it with 2.11. That'll obviously help it get better, and fast. But the last time we rushed out a gtk-gnome paired release, and got ourselves locked into the new APIs so that we couldn't back out, the result was that any distro actually paying attention would have noticed that our 'latest stable set' was *not actually stable* by our normal standards. *That* undermined the release process (or should have, if people paid attention, which it turns out they don't.) If we don't ship 2.8, it should be because our collective experience and our testing data is telling the distros this is not yet ready for prime time. By not shipping 2.8, we're not asking them to figure out what the latest stable set is- we're telling them what the latest stable set is, and telling them that gtk 2.8 is not part of that, because it is not likely to be stable, given our experience. If distros want to overrule that, that's fine, but honestly, aes, elijah, bkor, kmaraas and I know a fuck of a lot more about the stability of GNOME than any of the distros do*, so if they want to overrule that, that is their own problem. Luis *except JDS ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On Fri, 2005-06-10 at 10:21 -0400, Luis Villa wrote: But the last time we rushed out a gtk-gnome paired release, and got ourselves locked into the new APIs so that we couldn't back out, the result was that any distro actually paying attention would have noticed that our 'latest stable set' was *not actually stable* by our normal standards. *That* undermined the release process (or should have, if people paid attention, which it turns out they don't.) If we don't ship 2.8, it should be because our collective experience and our testing data is telling the distros this is not yet ready for prime time. By not shipping 2.8, we're not asking them to figure out what the latest stable set is- we're telling them what the latest stable set is, and telling them that gtk 2.8 is not part of that, because it is not likely to be stable, given our experience. If distros want to overrule that, that's fine, but honestly, aes, elijah, bkor, kmaraas and I know a fuck of a lot more about the stability of GNOME than any of the distros do*, so if they want to overrule that, that is their own problem. It's *not up to the GNOME release team* to say when a GTK+ release is stable. That's up to the GTK+ team. I think our general take on that is that the day we release 2.8.0 we are committed to ABI and API stability, but our general expectation from past experience is that we do find and fix significant numbers of bugs in the first few maintenance releases after that. But the GNOME release team has *no* ability to say don't ship GTK +-2.8.x until we release GNOME-2.14. My point there is not that I expect 2.8.0 to be buggy, but basically that when mclasen is deciding on what version of GTK+ to go into a Red Hat product, or when federico is figuring out the same thing for Novell, there's going to be a lot more information and factors available to them then to the release team several months previously. Regards, Owen signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On 6/10/05, Owen Taylor [EMAIL PROTECTED] wrote: On Fri, 2005-06-10 at 10:21 -0400, Luis Villa wrote: But the last time we rushed out a gtk-gnome paired release, and got ourselves locked into the new APIs so that we couldn't back out, the result was that any distro actually paying attention would have noticed that our 'latest stable set' was *not actually stable* by our normal standards. *That* undermined the release process (or should have, if people paid attention, which it turns out they don't.) If we don't ship 2.8, it should be because our collective experience and our testing data is telling the distros this is not yet ready for prime time. By not shipping 2.8, we're not asking them to figure out what the latest stable set is- we're telling them what the latest stable set is, and telling them that gtk 2.8 is not part of that, because it is not likely to be stable, given our experience. If distros want to overrule that, that's fine, but honestly, aes, elijah, bkor, kmaraas and I know a fuck of a lot more about the stability of GNOME than any of the distros do*, so if they want to overrule that, that is their own problem. It's *not up to the GNOME release team* to say when a GTK+ release is stable. That's up to the GTK+ team. I think our general take on that is that the day we release 2.8.0 we are committed to ABI and API stability, As an aside, when I say 'stable', I mean 'reliable for users', not 'API stable for developers', and maybe that is part of the confusion of this thread. I expect GNOME .0s to be both stable (in your sense) and reliable (in mine.) GTK 2.4.0 was stable in your sense, but not reliable in mine, and that is why release team is wary of telling people that a gnome .0 based on gtk 2.8.0 would be reliable. but our general expectation from past experience is that we do find and fix significant numbers of bugs in the first few maintenance releases after that. But the GNOME release team has *no* ability to say don't ship GTK +-2.8.x until we release GNOME-2.14. I'm not claiming we do or should. You get to release .0 whenever you want, and users get to use it whenever they want. Release-team gets to say when they think it is reliable, and hence worthy of being part of GNOME. Ideally your .0 and our .0 should have the same qualities, but in our past experience they have not. This whole conversation is unfortunately sounding very hostile, which was not my intent. Let me try to back it down a little bit and get it back to the first principles, explain why (IMHO) gtk 2.4.0 was not reliable enough for GNOME 2.6.0, and see if/where/when we can compromise from those. With GTK 2.4.0 and GNOME 2.6.0, 2.4.0 was not stable, and apps all over the desktop crashed, which made GNOME 2.6.0 look bad. This didn't happen with GNOME 2.10, mainly IMHO because 2.6.0 was released a full three months before GNOME 2.10 was, allowing for extensive testing and several GTK point releases. Avoiding a repeat of this very difficult problem is my primary concern. GNOME generally avoids this with three big strategies: * avoid entanglements and only release things that are ready: we look at apps case by case and if necessary reject them if they aren't ready on our timeline[1]. This only works if the apps do not provide API to other parts of GNOME, or if their API has not changed. Unfortunately, this can't be the case for GTK- we must be entangled for good testing to happen, so we can't just get to september and say 'gtk isn't ready, punt it.' This means that if we choose to go with gtk 2.8.x, 2.8.x *must* be rock-solid stable at the GNOME 2.12.0 date, we have to punt apps that have upgraded their deps to 2.8.x, or we have to slip. (Or we can ship a .0 we're not happy with, but I'd like to think that isn't an option.) * aggressive freeze schedules: we freeze early, and ask for early releases. As has been pointed out, this does reduce features in favor of stability. * extensive testing: while we've been doing a poorer job of this than we used to, we still rely heavily on extensive testing of unstable releases to make our .0 releases as stable as possible. Because people are nervous about testing gtk, we know it gets less testing than other parts of the stack, even though it needs it more. So, options as I see them: * don't depend on gtk 2.8. This is suboptimal for all of us, in that gtk gets less testing, is less stable, etc., but goes a long way towards guaranteeing a reliable platform for GNOME 2.12 development and deployment, which is important for everyone. * tentatively depend on 2.8, and if 2.8 is not reliable when we need to ship 2.12, punt all apps that have chosen to depend on 2.8 and can't remove those dependencies in time. This is pretty suboptimal, in that developers will be forced to make a choice- depend on 2.8 and risk being tossed from the release, or go the safe route, but not get the new features, and not contribute to testing. * do a hard
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On Fri, 2005-06-10 at 13:10 -0400, Luis Villa wrote: On 6/10/05, Owen Taylor [EMAIL PROTECTED] wrote: On Fri, 2005-06-10 at 10:21 -0400, Luis Villa wrote: But the last time we rushed out a gtk-gnome paired release, and got ourselves locked into the new APIs so that we couldn't back out, the result was that any distro actually paying attention would have noticed that our 'latest stable set' was *not actually stable* by our normal standards. *That* undermined the release process (or should have, if people paid attention, which it turns out they don't.) If we don't ship 2.8, it should be because our collective experience and our testing data is telling the distros this is not yet ready for prime time. By not shipping 2.8, we're not asking them to figure out what the latest stable set is- we're telling them what the latest stable set is, and telling them that gtk 2.8 is not part of that, because it is not likely to be stable, given our experience. If distros want to overrule that, that's fine, but honestly, aes, elijah, bkor, kmaraas and I know a fuck of a lot more about the stability of GNOME than any of the distros do*, so if they want to overrule that, that is their own problem. It's *not up to the GNOME release team* to say when a GTK+ release is stable. That's up to the GTK+ team. I think our general take on that is that the day we release 2.8.0 we are committed to ABI and API stability, As an aside, when I say 'stable', I mean 'reliable for users', not 'API stable for developers', and maybe that is part of the confusion of this thread. I expect GNOME .0s to be both stable (in your sense) and reliable (in mine.) GTK 2.4.0 was stable in your sense, but not reliable in mine, and that is why release team is wary of telling people that a gnome .0 based on gtk 2.8.0 would be reliable. but our general expectation from past experience is that we do find and fix significant numbers of bugs in the first few maintenance releases after that. But the GNOME release team has *no* ability to say don't ship GTK +-2.8.x until we release GNOME-2.14. I'm not claiming we do or should. You get to release .0 whenever you want, and users get to use it whenever they want. Release-team gets to say when they think it is reliable, and hence worthy of being part of GNOME. Ideally your .0 and our .0 should have the same qualities, but in our past experience they have not. I'd argue that we may well be straying to far on the reliable side for GNOME. I'm not convinced we can do interesting development, stabilize down completely, and release on a 6 month time schedule. If we want to get real world testing before the code freeze, then we have to have something that a lot of people are using within 4 months after the release cycle opens. Acknowledging that the initial release may have a few rough edges gives us some pipelining, where the final stabilization of the last cycle gets parallelized with the start of development of the next release set. I'm not arguing for any radical changes here, just the realization that the only way you get zero-boogs is by having zero-development. If we don't do that, then I think we need to think about switching to having phased releases of some sort (like the old RHL 6.0, 6.1, 6.2, 7.0 model) This whole conversation is unfortunately sounding very hostile, which was not my intent. Let me try to back it down a little bit and get it back to the first principles, explain why (IMHO) gtk 2.4.0 was not reliable enough for GNOME 2.6.0, and see if/where/when we can compromise from those. With GTK 2.4.0 and GNOME 2.6.0, 2.4.0 was not stable, and apps all over the desktop crashed, which made GNOME 2.6.0 look bad. This didn't happen with GNOME 2.10, mainly IMHO because 2.6.0 was released a full three months before GNOME 2.10 was, allowing for extensive testing and several GTK point releases. Avoiding a repeat of this very difficult problem is my primary concern. I think this is slightly exaggerating the situation ... there were definitely issues with the file selector, but the file selector wasn't used *that* extensively in 2.6.0. And on the other side, the file selector had been under development for quite a while, but there is only so far you can go in an unused version of GTK+ ... it took about a year of real world banging on the file chooser for it to get to a state that's pretty satisfactory now. 2.8.0/2.10.0 were almost certainly a better release because the file selector appeared in GNOME-2.6.0. Let me reiterate that the version of GTK+ that goes into GNOME-2.12 is up to the release team. At this point, GNOME-2.12 isn't going to be depending on Cairo in interesting ways, so there wouldn't be huge disruption from making GTK+-2.6.x the official GNOME-2.12 version. But I really do want to get Cairo out there and in use as soon as possible and we'll be putting Cairo/Pango-1.9/GTK+-2.7
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On Fri, 2005-06-10 at 17:49 -0400, Morten Welinder wrote: the problem with gtk+/cairo in a stable setting is that it has only seen testing and been designed for hello world. You need to consider something bigger! Thanks for telling me how I designed the gtk+/cairo integration, I had no idea. Try putting 600-1000 pango layouts on the screen at once. GTK+ 2.6 is already not very snappy with that. Then make sure your X server is not local so you get to suffer the roundtrips also. I would like to hear from you that this has been considered and perhaps even tested. We still have not gotten anywhere near the screen update speed we had in the 1.2 days. Rendering speed is 90% an X server issue. For non-local servers without Render, Cairo will allow us to eliminate the round-trips... a huge win. Wearing my application developer hat, I would say that using GTK+ 2.8 for the next Gnome is crazy. It isn't right to enlist the unsuspecting users as guinea pigs just because you are having trouble getting people to test. The Cairo integration was done prematurely and now we suffer. We love you too, Morten. Best regards, Owen signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
Owen, the problem with gtk+/cairo in a stable setting is that it has only seen testing and been designed for hello world. You need to consider something bigger! Try putting 600-1000 pango layouts on the screen at once. GTK+ 2.6 is already not very snappy with that. Then make sure your X server is not local so you get to suffer the roundtrips also. I would like to hear from you that this has been considered and perhaps even tested. We still have not gotten anywhere near the screen update speed we had in the 1.2 days. Wearing my application developer hat, I would say that using GTK+ 2.8 for the next Gnome is crazy. It isn't right to enlist the unsuspecting users as guinea pigs just because you are having trouble getting people to test. The Cairo integration was done prematurely and now we suffer. Glib 2.8, on the other hand, fine. That's not a revolution. It might as well get renamed back to 2.6.whatever. And btw., we still are not near a state where the file chooser is acceptable. The save-as mode really stinks while the open mode is only marginally acceptable. See http://blogs.gnome.org/view/mortenw/2005/05/25/1 for example. Morten ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
Frederic Crozat wrote: Hi all, I only discovered this morning by looking at James commit for jhbuild that GNOME 2.11/2.12 is supposed to ship with GTK+ 2.8 (and therefore Cairo) which might not have been obvious for anybody reading http://live.gnome.org/RoadMap (since there is only a reference to cairo used to replace libgnomecanvas/libart). And I'm not sure all GNOME hackers have realized we are supposed to switch to GTK+ 2.8/Cairo. For the record, the page I was looking at was: http://live.gnome.org/ReleasePlanning_2fTwoPointEleven_2fDeveloperPlatform If there is consensus to use GTK 2.6 for Gnome 2.12, then both jhbuild and that wiki page should be updated to reflect this. James. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On Thu, 2005-06-09 at 12:10 +0100, Gustavo J. A. M. Carneiro wrote: It has not been tested it was too soon to test. Why are people so afraid of gtk+ 2.7 without even trying it? It really is quite stable now. I think it's because in these enlightened times, people use the GNOME stack that comes out of jhbuild or Ubuntu Breezy. Both of these distribution methods are semi-official; jhbuild is meant to have The next version of GNOME, Breezy is The next version of Ubuntu, and switching to 2.7 for a trial period *without* having this conversation is ugly and liable to confuse people about what was actually decided. And Cairo does help developers significantly. Anyone doing any kind of drawing and printing will know what I mean. Like, imagine how abiword/gnumeric/criawips would benefit from this. Gnome Print is not an option for most of these programs simply because it's a Gnome library thus not cross platform or needs gnome. There's a great bias against gnome libraries nowadays, unfortunately... And even if it is slower now, it potencially may become much faster than current X11 drawing model, perhaps even when gtk+ 2.8 gets released. Please stop gtk/cairo FUD. Hey hey hey, let's stay calm here. GNOME necessarily works on a short-term-benefit model; the question we need to ask is Is going to GTK+ 2.8 in less than 6 months *definitely* not going to have any negative implications on that version of GNOME? And it's a fair question to ask, because last time we did this the answer was Yes, it did. We're blatantly going to use GTK+ 2.8 by 2.14 at the latest, but GTK+ does work on a cycle with a longer feature-implementing stage, and so necessarily a longer improvements-and-bug-fixing stage. Which is fine. But we need to be careful about it. No-one was implying that Cairo was a Bad Idea (tm), only whether we could be 99% sure of it being as stable as and as fast as the current stable GTK+ in a relatively short timescale. -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On Wed, 2005-06-08 at 11:30 -0400, Matthias Clasen wrote: - GObject introspection: The current prototype in the gobject-instrospection module in cvs is not ready for inclusion yet. I feel that we would do better to not rush this in 2.8 at this point. Agreed. Also adapting language bindings to use it will take much more time for development and testing than we have available until GNOME 2.10 freeze. Regards. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On Thu, 2005-06-09 at 14:39 +0100, Mark McLoughlin wrote: Matthias's mail basically says that that isn't going to be an issue this time and details what the GTK+ guys are doing to make sure of that. So, lets not get things mixed up here. Performance worries are very different from meeting-the-schedule worries. However, the cairo API stability issue does create a risk that GTK+ 2.7/2.8 will not meet GNOME's API freeze on July 11th. If it doesn't that would be the time for GNOME 2.11/12 to revert to GTK+ 2.6. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On 6/9/05, Jon K Hellan [EMAIL PROTECTED] wrote: On Thu, 2005-06-09 at 14:39 +0100, Mark McLoughlin wrote: If we're talking about performance/stability in the context of whether GNOME 2.12 should use GTK+ 2.8, we're effectively saying I think the GTK+ team might ship a unstable or unacceptably slow 2.8.0 release; GNOME shouldn't commit to using GTK+ 2.8 yet. I would hope that we would have more confidence in the judgement of the GTK+ team than that. Crashes and performance are very different types of problem. Crashes get fixed once they can be reproduced. Fixing bad performance can take a long time. Well, I haven't tested gtk2.7 since just after Cairo got added, so I can't tell whether there is a performance problem. Has anybody got numbers? I haven't seen this announced on gtk-devel or here, so: http://gtkperf.sourceforge.net/ Apparently this is a test tool to test gtk performance. Would be great to have someone test 2.7 with it. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
quote who=Mark McLoughlin I think these kind of questions are only relevant in the context of deciding on the *gtk* schedule. I don't think they're very relevant in the context of deciding whether GNOME 2.12 should use GTK+ 2.8. If we're all confident the schedules line up, then I don't think there's really any more discussion to be had. That said, we were pretty confident that previous attempts at lining up the schedules were going to work, but we were bitten in the end by late delivery *and* GTK+ being less robust than we're used to (spoilt brats that we are). So Mattias, it would be great if you could get agreement on feature culling and schedule changing from the GTK+ team, and let us know what the final decision is. Perhaps it's better for GTK+ to go for broke on the new stuff, and meet us for 2.14, perhaps not. But I think we can only safely target GTK+ 2.6 at the moment, given our past experience and information we have to hand. - Jeff -- OSCON 2005: August 1st-5th http://conferences.oreillynet.com/os2005/ It's all a blur of a bunch of people having battles on different plants (sic).- Mary Gardiner on Star Wars ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On Fri, 2005-06-10 at 01:17 +1000, Jeff Waugh wrote: quote who=Mark McLoughlin I think these kind of questions are only relevant in the context of deciding on the *gtk* schedule. I don't think they're very relevant in the context of deciding whether GNOME 2.12 should use GTK+ 2.8. If we're all confident the schedules line up, then I don't think there's really any more discussion to be had. That said, we were pretty confident that previous attempts at lining up the schedules were going to work, but we were bitten in the end by late delivery *and* GTK+ being less robust than we're used to (spoilt brats that we are). So Mattias, it would be great if you could get agreement on feature culling and schedule changing from the GTK+ team, and let us know what the final decision is. Perhaps it's better for GTK+ to go for broke on the new stuff, and meet us for 2.14, perhaps not. We'll discuss it in the next team meeting, early next week. But I think we can only safely target GTK+ 2.6 at the moment, given our past experience and information we have to hand. There is not that much new API apart from Cairo, the new functions fit on one page. So targeting the 2.6 API is not a big loss, unless you were planning to convert your drawing code to Cairo... Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On 6/9/05, Jon K Hellan [EMAIL PROTECTED] wrote: On Thu, 2005-06-09 at 10:49 -0400, Luis Villa wrote: first 'column' of times is gtk 2.6, second is gtk/cairo HEAD of yesterday, both with the Mist theme: GtkEntry - time: 0.43 0.76 GtkComboBox - time: 12.61 15.30 GtkComboBoxEntry - time: 11.95 13.25 GtkSpinButton - time: 0.65 1.09 GtkProgressBar - time: 0.53 0.87 GtkToggleButton - time: 2.17 4.42 GtkCheckButton - time: 3.41 3.27 GtkRadioButton - time: 4.29 3.96 GtkTextView - Add text - time: 91.88 268.67 GtkTextView - Scroll - time: 43.17 190.83 GtkDrawingArea - Lines - time: 8.40 8.48 GtkDrawingArea - Circles - time: 13.38 13.58 GtkDrawingArea - Text - time: 48.70 29.99 GtkDrawingArea - Pixbufs - time: 11.71 11.46 --- Total time: 253.31 565.94 I should have mentioned that this was with N=1000; jkh, I'm assuming you did the default n=100? Here are my numbers. The tendency is the same. I'm comparing the head of the 2.6 branch in cvs with HEAD. Both locally compiled with the same jhbuild setup. Default theme. Gtk branch 2.6 HEAD time time GtkEntry 0.04 0.07 GtkComboBox 1.11 1.51 GtkComboBoxEntry 0.99 1.17 GtkSpinButton0.07 0.11 GtkProgressBar 0.04 0.09 GtkToggleButton 0.21 0.41 GtkCheckButton 0.34 0.44 GtkRadioButton 0.41 0.65 GtkTextView - Add text 1.62 2.82 GtkTextView - Scroll 0.34 1.39 GtkDrawingArea - Lines 0.54 0.49 GtkDrawingArea - Circles 1.22 1.08 GtkDrawingArea - Text3.98 5.05 GtkDrawingArea - Pixbufs 1.23 1.00 --- --- Total time: 12.16 16.27 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
Somewhat random set of comments: - For all the reasons that it makes sense for GNOME to stick to it's published schedules, it makes sense for GTK+ to stick to it's published schedules. While we haven't always done a great job in the past (GTK+-2.2.0 was particularly bad), that doesn't mean that we have license to slip. There are certainly people who want to slip the GTK+-2.6 schedule so we can get in introspection or libglade integration, but in the end, slipping a few weeks or a month isn't going allow us to do a really good job on those. So, regardless of what the GNOME release team decides, I think we should stick to the schedule we published. - To be realistic, if GNOME-2.12 is released after GTK+-2.8, most distributors are going to ship using them together. So, the release team could decide to go with 2.6 even with the current GTK+ schedule, but the result then would be less testing of what people actually ship. - For new APIs to be done well, we need language binding author attention. If we decided to slip out the GTK+ schedule a month or two and add more features, I'm not sure that those features would get sufficient language binding author attention. - While GNOME isn't going to be using many Cairo features for 2.12, getting Cairo-1.0 and GTK+-2.8 out there early is important to getting apps out using GTK+ and Cairo together for 2.14. I think that a GTK+ with Cairo and small features is very realistic on the schedule on gtk.org/plan/2.8. One inherent difficulty with the way that GNOME is working these days is with a new feature-release every 6 months, we don't really give ourselves any time for .0 shakeout. A major code change can easily take 6 months - after release - to shake out. By that time, with our scheduling, we've released more major code changes. Honestly, I expect some portability issues with Cairo after 1.0 is released. It's not going to work well on some set of older X servers, and we'll have to work around those issues. But people aren't going to find those issues until GNOME or a major app is depending on Cairo. Regards, Owen signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On Thu, 2005-06-09 at 10:49 -0400, Luis Villa wrote: On 6/9/05, Luis Villa [EMAIL PROTECTED] wrote: Went ahead and did it myself. TextView is brutally slower (300-400%), some other things are 25-30% slower, and some things actually get faster. Disclaimer: I'm pretty sure I did this right and I'm linking against the right stuff, but these numbers should be confirmed by an expert, and I can't speak to the validity of the tool's measurements itself, except to note that scrolling in a textview area is *visibly* slower. The data: first 'column' of times is gtk 2.6, second is gtk/cairo HEAD of yesterday, both with the Mist theme: With the Mist theme, you are testing mixed Cairo and GDK rendering. Right now, that could conceivably hide some performance problems with Cairo. In the future, there are some performance optimizations that will be disabled when you are mixing Cairo and GDK rendering. The GTK+ builtin theme probably gives more of an accurate feel for GTK+/Cairo performance. What the appropriate theme to test is does depend on what we will be shipping for GNOME-2.10 as the default, of course. Which is likely not the GTK+ builtin theme. GtkEntry - time: 0.43 0.76 GtkComboBox - time: 12.61 15.30 GtkComboBoxEntry - time: 11.95 13.25 GtkSpinButton - time: 0.65 1.09 GtkProgressBar - time: 0.53 0.87 GtkToggleButton - time: 2.17 4.42 GtkCheckButton - time: 3.41 3.27 GtkRadioButton - time: 4.29 3.96 GtkTextView - Add text - time: 91.88 268.67 GtkTextView - Scroll - time: 43.17 190.83 GtkDrawingArea - Lines - time: 8.40 8.48 GtkDrawingArea - Circles - time: 13.38 13.58 GtkDrawingArea - Text - time: 48.70 29.99 GtkDrawingArea - Pixbufs - time: 11.71 11.46 Without studying what these benchmarks are actually doing, I'd consider them pretty encouraging ... some operations got faster, and what got slower is something we have in our sights already ... cairo_scaled_font_glyph_extents(). (GtkTextView performance is text measuring performance.) There is an obvious big-hammer approach that would allow us to get rid of that ... to put a cache in front of it so that we avoid calling into Cairo entirely, but I'd like to see what we can do inside of Cairo first. Regards, Owen signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On 6/8/05, Mark McLoughlin [EMAIL PROTECTED] wrote: Hey, I guess there's quite a few benefits/risks to be weighed up here: - The benefit of having cool new rendering stuff in GNOME 2.12 - The benefit of being able to use all the other new APIs in GTK+ 2.8 for GNOME 2.12 - The benefit of getting all this stuff tested early (i.e. before GTK+ 2.8 is released, rather than after) I'm all in favor of *testing* gtk 2.8 as much as possible now (so I think it should be left in jhbuild), but I'm very nervous about shipping with it at this point- we all know HEAD does not get as much testing as it should, and gtk 2.8 seems like some very big changes with potentially huge stability implications. Basically, unless Ubuntu breezy starts shipping it, or Fedora makes a very active push to get people to use it in Rawhide, I'm very nervous about shipping anything we'd call a .0 linking against gtk 2.8. Luis - The extra incentive for people to help with getting the rendering stuff optimized vs. - The risk of the GTK+ 2.8 schedule slipping, causing a slip in the GNOME 2.12 schedule - The risk that performance problems with the rendering stuff might put some people off using GNOME 2.12 Although I was pretty nervous about this too at first, the benefits certainly seem to outweigh the risks when you spell them out like that. Cheers, Mark. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On 6/8/05, Luis Villa [EMAIL PROTECTED] wrote: On 6/8/05, Mark McLoughlin [EMAIL PROTECTED] wrote: Hey, I guess there's quite a few benefits/risks to be weighed up here: - The benefit of having cool new rendering stuff in GNOME 2.12 - The benefit of being able to use all the other new APIs in GTK+ 2.8 for GNOME 2.12 - The benefit of getting all this stuff tested early (i.e. before GTK+ 2.8 is released, rather than after) I'm all in favor of *testing* gtk 2.8 as much as possible now (so I think it should be left in jhbuild), but I'm very nervous about shipping with it at this point- we all know HEAD does not get as much testing as it should, and gtk 2.8 seems like some very big changes with potentially huge stability implications. Basically, unless Ubuntu breezy starts shipping it, or Fedora makes a very active push to get people to use it in Rawhide, I'm very nervous about shipping anything we'd call a .0 linking against gtk 2.8. Oh, and after the last time we did this, the release team swore mighty oaths to never depend on a released-close-to-gnome-schedule GTK again, since it jeopardizes our release schedule for something that is less tested than the rest of the stack and which in many cases isn't widely used because developers haven't had time to integrate it. I suppose we could reconsider that, but we did it the last time for the same reasons Mark listed, more or less. As a result we had to delay our release and (speaking with my QA hat on) after .0 we still had to track down several issues in gtk that were caused by rushing out a component low-in-the-stack with insufficient real-world testing. So, yeah, I'm pretty strongly against this, though I'm open to persuasion. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On Wed, 2005-06-08 at 09:09 -0400, Luis Villa wrote: Oh, and after the last time we did this, the release team swore mighty oaths to never depend on a released-close-to-gnome-schedule GTK again, [snip] I think we'd love them to be in sync. They are getting there, and if they are there, I think we'd be happy with that. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On Wed, 2005-06-08 at 09:09 -0400, Luis Villa wrote: So, yeah, I'm pretty strongly against this, though I'm open to persuasion. aolMe too/aol, for all the reasons Luis listed. I remember our r-t discussions basically concluded that we'd made a mistake depending on GTK+ for 2.6. 2.6 had stability issues. -- Andrew ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
I guess a fair compromise would be to aim for using gtk 2.8 for 2.12, but not using any new functionality in gtk 2.8. That way if it turns out 2.8 is not stable enough we can roll back to 2.6 before release. On the other side it is stable enough then we ensure its gets widely distributed and tested so we can start taking advantage of it for 2.14. Christian On Wed, 2005-06-08 at 14:42 +0100, Andrew Sobala wrote: On Wed, 2005-06-08 at 09:09 -0400, Luis Villa wrote: So, yeah, I'm pretty strongly against this, though I'm open to persuasion. aolMe too/aol, for all the reasons Luis listed. I remember our r-t discussions basically concluded that we'd made a mistake depending on GTK+ for 2.6. 2.6 had stability issues. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
