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
Valgrind logs off a fresh jhbuild of 2.12
Hi. I tried building HEAD off jhbuild last night and today and the result of logging in doing some small tasks in the panel and opening a terminal etc. I filed one bug against gdk with a cairo related leak already, and I found another one that I have a patch for in gnome-screenshooter. Other than that I had some redraw problems on the desktop. It seemed to draw text and icons repeatedly over the existing one without refreshing the desktop, the new text and icon also moved up slightly for each iteration so it looked really bad after a while. Possibly som cairo issue? Screenshot of this is here: http://www.gnome.org/~kmaraas/skewed-desktop.png I had very few problems building this. The ones I remember are - gst-plugins not building because of some gcc4 warning - gnome-media needed a build fix (now in CVS) - eel doesn't build unless you pass it --enable-more-warnings=no when using gcc4 - probably some other issues I forgot :-) Hope someone finds this useful Cheers Kjartan ___ 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
gnome-icon-theme has been branched
I just branched gnome-icon-theme for gnome 2.10. The branchpoint is based off the last 2.10 release. -- dobey ___ 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
ggv/gpdf and evince
I think there seems to be a very strong consensus that ggv/gpdf should be replaced by evince in 2.12. Does anyone object to me going ahead and removing them from the jhbuild moduleset and adding evince? Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ggv/gpdf and evince
Luis Villa [EMAIL PROTECTED] writes: I think there seems to be a very strong consensus that ggv/gpdf should be replaced by evince in 2.12. Does anyone object to me going ahead and removing them from the jhbuild moduleset and adding evince? Go for it. -Jonathan ___ 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: List of maintainers tips for maintainers
quote who=Bastien Nocera On Thu, 2005-06-09 at 22:50 +0200, Vincent Untz wrote: Hi all, Could all the module maintainers add themselves in the maintainer column on the Desktop modules list [1] and on the Developer Platform modules list [2]. It might also be useful for the platform bindings [3]. [1] http://live.gnome.org/ReleasePlanning/TwoPointEleven/Desktop Why is it that nautilus-media's still in there? Human error is the likely reason. It's a wiki, you know. *hint* - Jeff -- GNOME Summit 2005: October 10th-12thhttp://live.gnome.org/Boston2005 I don't want the world, I just want your half. - They Might Be Giants, Ana Ng ___ 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
