Re: control-center 2.13.90 released
Hey, On Mon, 2006-02-06 at 16:10 -0500, Matthias Clasen wrote: On 2/6/06, Elijah Newren [EMAIL PROTECTED] wrote: Was there a reason to do that instead of using Glynn's patch from bug 327335 to revert this specific change? 1) I was not aware of that bug and patch 2) We also want the icons back So what's the situation of this - are the various patches going to be reverted? It seems like there's a *strong* disagreement for these changes by many people in this thread that these changes. It seems to me that from a corporate point of view, there's 2 vendors, Red Hat and Sun, have already reverted these changes and shipping a different version of the capplet. Aside from the 'design by committee' set of blog posts that I haven't had a chance to catch up on, anyone willing to give a summary of where things stand? I notice that these changes landed *after* 2.13.5 - that's well late in the cycle, no? It feels like we should at least revert now, find some status quo and then get some good discussion for making those changes in the 2.16 timeframe. thoughts? Glynn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
Federico Mena Quintero wrote: - how long does nautilus take to pick up the pixmap and repaint its desktop window. That takes about 1 second for me, due to XRENDER bugs. This last one should be better on Radeon cards if you cvs update your GTK+. I put a workaround for the relevant Cairo/XRENDER bugs. I applied the patch (gtk2-117163-cairo-repeat-pattern-workaround.diff), to Gentoo's gtk+-2.8.11 and it makes Gnome much smoother and snappier, even running at 600MHz off of battery. I feel that combined with the removal of the 300ms delay, the problem is solved. Now, if only to get the useful icons back... sigh... --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
On 2/6/06, Federico Mena Quintero [EMAIL PROTECTED] wrote: On Wed, 2006-02-01 at 12:04 -0600, Federico Mena Quintero wrote: Has anyone figured these out? :) I have put a patch which removes the delays from the capplet and gnome-settings-daemon in http://bugzilla.gnome.org/show_bug.cgi?id=330168 With that patch, background switching is acceptably fast for me. Note that the patch is against control-center-2.12.3, since Fedora has switched back to the 2.12 version of the background capplet... Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
Matthias Clasen wrote: 2) We also want the icons back Yes, this is definitely still a big issue. Unlike the instant-apply behaviour, this particular change was never explained in detail. The dialog looks very much out of place without them. I find the dialog harder to use without them. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
On Mon, 2006-02-06 at 16:16 -0500, Pat Suwalski wrote: Matthias Clasen wrote: 2) We also want the icons back Yes, this is definitely still a big issue. Unlike the instant-apply behaviour, this particular change was never explained in detail. 1) GtkOptionMenu is deprecated. 2) GtkComboBox makes it very difficult to add icons to the drop-down. 3) The icons were a total hack anyway, and broke a11y functionality 4) We have too many icons in use in the desktop, and so I, as well as the artists who maintain the icons, want to reduce that number 5) To help separate the controls within the dialog for managing the wallpapers and properties on them, and the buttons for the dialog This is also a problem that we've seen a lot of in the file chooser dialog in testing as well. Users will often click the Add button on the left, under the bookmarks list, because they want to add a wallpaper or attachment to a mail, or whatever. So, I removed the icons from the Add/Remove buttons to help with this as well, although I can't do it in the file chooser itself. Some users would also try to click the Add Wallpaper button, in an attempt to set the wallpaper, as they don't expect it to change immediately when selected, and do not know that the close button won't revert their selection. -- dobey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
Rodney Dawes wrote: 1) GtkOptionMenu is deprecated. 2) GtkComboBox makes it very difficult to add icons to the drop-down. These two are valid points. 3) The icons were a total hack anyway, and broke a11y functionality 4) We have too many icons in use in the desktop, and so I, as well as the artists who maintain the icons, want to reduce that number 5) To help separate the controls within the dialog for managing the wallpapers and properties on them, and the buttons for the dialog These I have a hard time buying. Taking this from the opposite approach, how on earth is a user supposed to know the difference between Scaled and Fill Screen without that little icon to show what's going to happen? I personally find the tiled icon very helpful, as well as the Add and Remove icons. They tell me a lot, help me make a quick decision. The gradient icons are less useful, but they show a little preview of what will happen without the composed textured like in the larger preview icons. They are needed. It used to be that adding icons to interfaces would help dumb users (or me on a Monday morning). Now we're being told the opposite? --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
Quoting Pat Suwalski [EMAIL PROTECTED]: Rodney Dawes wrote: 1) GtkOptionMenu is deprecated. 2) GtkComboBox makes it very difficult to add icons to the drop-down. (1) is true, however it's also not going away any time soon; (2) could be described as 'complete cock', it is quite possible to add these icons in. It is admittedly a little bit more work than it was with GtkOptionMenu, but not 'very difficult'. --d ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
On 2/6/06, Rodney Dawes [EMAIL PROTECTED] wrote: 1) GtkOptionMenu is deprecated. 2) GtkComboBox makes it very difficult to add icons to the drop-down. What a silly excuse. Everybody else seems to manage. We even ship a porting guide in.the api docs and an illustrated example in gtk-demo. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
On Thu, 2006-02-02 at 23:39 +, Iain * wrote: On 2/1/06, Federico Mena Quintero [EMAIL PROTECTED] wrote: - how long does nautilus take to pick up the pixmap and repaint its desktop window. That takes about 1 second for me, due to XRENDER bugs. Part of that second is a 300ms timeout before nautilus does anything, to let GConf change all the values. See libnautilus-private/nautilus-directory-background.c:328 hmm, can't we just use a ChangeSet and do all changes at once and thus remove the timeout? -- Rodrigo Moya [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
On 02/02/2006 09:23 AM, Rodney Dawes wrote: The hope is to fix all of the problems. Not following the HIG is something that I would consider a problem. I fixed the dialog to follow the HIG. I'd just like to point out that at least 2 of the 3 people listed in the HIG's credits[1] have expressed[2] this is the wrong solution[3], so it seems to me that perhaps the HIG as published is confusing and needs to be fixed, but I'd say that in any case if the HIG authors are saying this decision is wrong, following the HIG doesn't sound as good an argument anymore [1] http://developer.gnome.org/projects/gup/hig/2.0/credits.html [2] http://bugzilla.gnome.org/show_bug.cgi?id=327335#c9 [3] http://bugzilla.gnome.org/show_bug.cgi?id=327335#c26 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
On 2/3/06, Rodrigo Moya [EMAIL PROTECTED] wrote: On Thu, 2006-02-02 at 23:39 +, Iain * wrote: On 2/1/06, Federico Mena Quintero [EMAIL PROTECTED] wrote: - how long does nautilus take to pick up the pixmap and repaint its desktop window. That takes about 1 second for me, due to XRENDER bugs. Part of that second is a 300ms timeout before nautilus does anything, to let GConf change all the values. See libnautilus-private/nautilus-directory-background.c:328 hmm, can't we just use a ChangeSet and do all changes at once and thus remove the timeout? Apparently we do, this is the comment just above the timeout /* * Wallpaper capplet changes picture, background color and placement with * gconf_change_set API, but unfortunately, this operation is not atomic in * GConf as it should be. So we update background after small timeout to * let GConf change all values. */ Is this a bug in GConf? Was it a bug which has since been fixed? Can it be fixed? Should it be? iain ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
On 2/1/06, Federico Mena Quintero [EMAIL PROTECTED] wrote: - how long does nautilus take to pick up the pixmap and repaint its desktop window. That takes about 1 second for me, due to XRENDER bugs. Part of that second is a 300ms timeout before nautilus does anything, to let GConf change all the values. See libnautilus-private/nautilus-directory-background.c:328 iain ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
On Thu, Feb 02, 2006 at 09:23:36AM -0500, Rodney Dawes wrote: As I'm on older crappy hardware I guess I should sit out this release cycle entirely as an even slower Gnome would probably kill it. (2) shipping GNOME 2.14 with gtk-engines 2.6, leaving people who giving us more time to optimise gtk-engines/cairo/X I expect this would be unpopular with developers (especialy dobey). How many developers have really crappy hardware? (ie 3 years old) I could care less what version of gtk-engines we ship. It's not the problem, and I don't use any of the engines in it anyway. I doubt that the problem is even the fact that gtk+ uses cairo. Cairo can fill a full-screen rectangle on my crappy 3 year old Radeon 7500 in about 0.0007 seconds. That's also with X 6.8.2. On my Radeon FireGL X1 at a lower resolution, on X 6.9.0, it takes about 0.007 seconds for the same test case code that Federico pointed me to, to run. That's significantly slower, for a significantly better video card. However, in both cases, the amount of time taken, is nowhere near the amount of time it takes to actually render the background. I don't know why gtk-engines was even mentioned in this thread, or why Davyd alluded to it being the cause of the slowness, on his blog. There are known issues with Cairo and doing large exposes and how is breaks XAA. This is why minimising windows for many people is now mind-bendingly slow, as is coming back from screensave. Some people have started shipping a workaround in their X.org configs I understand (to turn off XAA offscreen pixmaps) and I don't know if EXA is affected. I don't have any details beyond this, you will need to talk to a graphics person. --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
On 2/2/06, Rodney Dawes [EMAIL PROTECTED] wrote: If the hope is to change it back when things get faster then this current change is inflicting unnecessary software churn on users. The hope is to fix all of the problems. Not following the HIG is something that I would consider a problem. I fixed the dialog to follow the HIG. Rotely following the HIG (rotely following any guidelines) because they are guidelines, instead of working to fix underlying problems, is the height of idiocy. Or laziness. Or both. Luis (thinking maybe the HIG should have a note: 'If your software used to be fast enough for 'OK', and now it isn't, you should get out the profiler and fix the performance instead of getting out glade.' Or maybe the first page of the HIG should say, in bold print, 'Fix the problem, not the symptom.' I'd say it should say 'don't be an idiot' but maybe that isn't clear enough.) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
On Wed, 1 Feb 2006, Shaun McCance wrote: Date: Wed, 01 Feb 2006 18:27:33 -0600 From: Shaun McCance [EMAIL PROTECTED] To: desktop-devel-list@gnome.org Subject: Re: control-center 2.13.90 released On Wed, 2006-02-01 at 17:49 +, Alan Horkan wrote: From: Davyd Madeley [EMAIL PROTECTED] At this stage in the game, I think we should look at doing three things: (1) reverting the UI change, it is a bandaid fix to a deeper problem; If the hope is to change it back when things get faster then this current change is inflicting unnecessary software churn on users. As I'm on older crappy hardware I guess I should sit out this release cycle entirely as an even slower Gnome would probably kill it. (2) shipping GNOME 2.14 with gtk-engines 2.6, leaving people who giving us more time to optimise gtk-engines/cairo/X I expect this would be unpopular with developers (especialy dobey). How many developers have really crappy hardware? (ie 3 years old) Developers be damned. Let's take care of our users. (Yeah but I know Dobey is going to hate me for complaining and he did the hard work so I should try and be nice about it.) To rephrase what I said earlier if the user interface is being changed with the expectation of chaning it back for the following release of Gnome then it is is likely to cause unnecesary confusion. Whizbang flashiness is great, but if we can't deliver it quickly on moderate hardware, then it needs to sit on the sidelines until we can. My machine is around two years old. It is not a crappy machine. I had to go back to an old gtk-engines because I just couldn't handle it anymore. All I know is Gnome is not yet a more responsive solution than Windows 2000 on the same machine. There are still a variety of reasons to prefer Gnome though. -- Alan Horkan http://advogato.org/person/AlanHorkan/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
Pat Suwalski wrote: Elijah Newren wrote: http://bugzilla.gnome.org/show_bug.cgi?id=327335. I'm with Federico though in thinking we should make it fast instead. If memory serves, the background resampling and applying used to be very snappy and got significantly slower when everything moved to cairo. At this point, I have the X hashed background until a few seconds after my panels show up. If this is the case, has anyone pinged Carl Worth about the slowdown, to see if it can be fixed? (either on our end by doing the rendering in a more efficient way, or by adding fast paths to Cairo for the particular calls). James. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
On Mon, 2006-01-30 at 13:52 -0700, Elijah Newren wrote: I also feel that it looks odd and out of place (Why else would I click on a different image than to have it be my background?). It appears this was done because the change was too slow -- at least that's the valid reason I could find at http://bugzilla.gnome.org/show_bug.cgi?id=327335. I'm with Federico though in thinking we should make it fast instead. And in the meantime, a bit of pointer feedback would probably relieve any why is nothing happening? symptoms on the instant-apply front. Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:[EMAIL PROTECTED]Java Desktop System Group http://ie.sun.com +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
On Tue, 2006-01-31 at 12:49 +, Calum Benson wrote: On Mon, 2006-01-30 at 13:52 -0700, Elijah Newren wrote: I also feel that it looks odd and out of place (Why else would I click on a different image than to have it be my background?). It appears this was done because the change was too slow -- at least that's the valid reason I could find at http://bugzilla.gnome.org/show_bug.cgi?id=327335. I'm with Federico though in thinking we should make it fast instead. And in the meantime, a bit of pointer feedback would probably relieve any why is nothing happening? symptoms on the instant-apply front. The gnome-background-properties dialog has no idea how long it will actually take for the settings to take effect, as it does not control the actual drawing on the background. The gconf calls to set the keys succeed and return instantly, which means that changing the pointer in the capplet itself, based on that information, would be totally useless. A timeout would still be needed, to slow the UI down. -- dobey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Performance (wasRe: control-center 2.13.90 released)
Hi, Do we have a general performance problem currently? My Fedora Rawhide (FC5) desktop is slow as hell atm. I thought at first it was a distribution/development edition issue, but talking to people running Dapper at the office they are experiencing the same. One example, starting Totem for the first time takes about 30 seconds on my system now. Stopping and restarting totem multiple times lets me get that down to around 8-10 seconds. Christian On Tue, 2006-01-31 at 18:10 +0800, James Henstridge wrote: Pat Suwalski wrote: Elijah Newren wrote: http://bugzilla.gnome.org/show_bug.cgi?id=327335. I'm with Federico though in thinking we should make it fast instead. If memory serves, the background resampling and applying used to be very snappy and got significantly slower when everything moved to cairo. At this point, I have the X hashed background until a few seconds after my panels show up. If this is the case, has anyone pinged Carl Worth about the slowdown, to see if it can be fixed? (either on our end by doing the rendering in a more efficient way, or by adding fast paths to Cairo for the particular calls). James. ___ 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: control-center 2.13.90 released
Thomas Wood wrote: I was thinking of doing some work on the theme manager UI for 2.16. Should the theme manager be switched to explicit apply too? It often takes more than a second to apply a theme. The best way to see what your desktop will look like is to click one of the themes and see what your desktop looks like! There's a handy revert button, and it should be quite discoverable to click back on the theme that was previously selected. Is this not the case? --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
Pat Suwalski wrote: Thomas Wood wrote: I was thinking of doing some work on the theme manager UI for 2.16. Should the theme manager be switched to explicit apply too? It often takes more than a second to apply a theme. The best way to see what your desktop will look like is to click one of the themes and see what your desktop looks like! There's a handy revert button, and it should be quite discoverable to click back on the theme that was previously selected. Is this not the case? This isn't really the issue. The problem is that the apply procedure takes more than a second to complete, thus violating the previously mentioned section of the HIG about instant apply. -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Performance (wasRe: control-center 2.13.90 released)
Le mardi 31 janvier 2006 à 15:17 +0100, Christian Fredrik Kalager Schaller a écrit : Hi, Do we have a general performance problem currently? My Fedora Rawhide (FC5) desktop is slow as hell atm. I thought at first it was a distribution/development edition issue, but talking to people running Dapper at the office they are experiencing the same. One example, starting Totem for the first time takes about 30 seconds on my system now. Stopping and restarting totem multiple times lets me get that down to around 8-10 seconds. I think you have been hit by fontconfig 2.3.93 caching bug, which should be more of less fixed since today in CVS. -- Frederic Crozat [EMAIL PROTECTED] Mandriva ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Performance (wasRe: control-center 2.13.90 released)
On 1/31/06, Christian Fredrik Kalager Schaller [EMAIL PROTECTED] wrote: Hi, Do we have a general performance problem currently? My Fedora Rawhide (FC5) desktop is slow as hell atm. I thought at first it was a distribution/development edition issue, but talking to people running Dapper at the office they are experiencing the same. One example, starting Totem for the first time takes about 30 seconds on my system now. Stopping and restarting totem multiple times lets me get that down to around 8-10 seconds. Startup time problems in rawhide are mostly fontconfig. Still trying to sort that out. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
On Tue, 2006-01-31 at 09:16 -0500, Pat Suwalski wrote: James Henstridge wrote: If this is the case, has anyone pinged Carl Worth about the slowdown, to see if it can be fixed? (either on our end by doing the rendering in a more efficient way, or by adding fast paths to Cairo for the particular calls). I wonder if it would make sense to implement the same technique as eog uses, with a first rough-pass for a very fast application, and a better pass when it becomes available? That's only necessary when we can't make it fast enough to begin with! :-) I think the first step is for someone to simply spend a little time figuring out what is slow: - Gradients - Scaled images - Solid color backgrounds? If we are scaling images *via Cairo* that is known to be slow with older X servers; if investigation proves that actually is the problem, it can be worked around. Regards, Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Performance (was Re: control-center 2.13.90 released)
Christian Fredrik Kalager Schaller wrote: Hi, Do we have a general performance problem currently? My Fedora Rawhide (FC5) desktop is slow as hell atm. I thought at first it was a distribution/development edition issue, but talking to people running Dapper at the office they are experiencing the same. One example, starting Totem for the first time takes about 30 seconds on my system now. Stopping and restarting totem multiple times lets me get that down to around 8-10 seconds. Christian It'd be interesting if you could try changing your theme (I assume you are using Clearlooks) to Glider and seeing what difference that makes. The Glider theme uses the Smooth engine, which is not currently using cairo. Clearlooks on the other hand, is now using cairo almost exclusively. If there is a significant difference in speed then we may need to look at holding back cairo enabled gtk-engines in GNOME, at least until significant speed improvements are made to cairo. -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
On Tue, 2006-01-31 at 14:38 +, Thomas Wood wrote: This isn't really the issue. The problem is that the apply procedure takes more than a second to complete, thus violating the previously mentioned section of the HIG about instant apply. I saw a figure quoted that the average time to apply was 1.4 seconds. How did that get evaluated? The machine I'm on at the moment isn't old, but it definitely isn't that new either, and it takes under half a second to change the background. One thing I noticed is that the time is greatly affected by whether Nautilus is drawing the desktop or not. I normally don't, but when turned on the time was up to around a second. Drawing the icons and text might take extra time, but is there something Nautilus is doing that causes it to go that much slower? Cheers, James Doc Livingston -- Never offend people with style when you can offend them with substance. --Sam Brown 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: control-center 2.13.90 released
On Tue, 2006-01-31 at 14:38 +, Thomas Wood wrote: Pat Suwalski wrote: Thomas Wood wrote: I was thinking of doing some work on the theme manager UI for 2.16. Should the theme manager be switched to explicit apply too? It often takes more than a second to apply a theme. The best way to see what your desktop will look like is to click one of the themes and see what your desktop looks like! There's a handy revert button, and it should be quite discoverable to click back on the theme that was previously selected. Is this not the case? This isn't really the issue. The problem is that the apply procedure takes more than a second to complete, thus violating the previously mentioned section of the HIG about instant apply. This is true, although it doesn't usually take more than a second to visibly do /something/, which is perhaps what the HIG should really say. Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:[EMAIL PROTECTED]Java Desktop System Group http://ie.sun.com +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
Thomas Wood wrote: Is this not the case? This isn't really the issue. The problem is that the apply procedure takes more than a second to complete, thus violating the previously mentioned section of the HIG about instant apply. Then the solution should be to paint the desktop with the selected background colour until the image is ready. The colour could be applied instantly, which would give some notion of progress. But the painting speed could definitely be fixed. Unfortunately, I've noticed severe slowdowns in painting throughout the desktop since Cairo came in. It's a worthwhile change, but optimization is required. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
On Tue, 2006-01-31 at 10:14 -0500, Owen Taylor wrote: I think the first step is for someone to simply spend a little time figuring out what is slow: - Gradients - Scaled images - Solid color backgrounds? If we are scaling images *via Cairo* that is known to be slow with older X servers; if investigation proves that actually is the problem, it can be worked around. I'm pretty sure that this is the same bug as https://bugs.freedesktop.org/show_bug.cgi?id=4320 At Suse we have Stefan Dirsch looking into that particular bug. This may help the capplet, but again, someone needs to profile the capplet to see what is going on. Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Performance (was Re: control-center 2.13.90 released)
On Tue, 2006-01-31 at 15:31 +, Thomas Wood wrote: It'd be interesting if you could try changing your theme (I assume you are using Clearlooks) to Glider and seeing what difference that makes. The Glider theme uses the Smooth engine, which is not currently using cairo. Clearlooks on the other hand, is now using cairo almost exclusively. If there is a significant difference in speed then we may need to look at holding back cairo enabled gtk-engines in GNOME, at least until significant speed improvements are made to cairo. -Thomas I switched back from Clearlooks cairo version to the Mist theme: everything is nice and fast now. With cairo-clearlooks, clicking a cleared number in gnome-mines, I could follow the bombsquad clearing the field of known not-mine squares. With Mist, these fields get uncovered instantly. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
Owen Taylor wrote: I think the first step is for someone to simply spend a little time figuring out what is slow: - Gradients - Scaled images - Solid color backgrounds? 30 seconds of experimentation shows me that scaling and filling are slow, while tiling is very fast. The very strange discrepancy is that when setting an image smaller than the screen, centering is slow! If we are scaling images *via Cairo* that is known to be slow with older X servers; if investigation proves that actually is the problem, it can be worked around. All of my observations are on X.org 7.0.0 with the radeon driver. There were previously (6 months ago?) bigger performance problems, but when I opened a freedesktop bug about it, the whole XaaOffscreenPixmaps issues was brought up. I don't know how that concluded. Adding the Exa extension slows down my r200 card another 2-3 times. But that is getting off-topic. It used to be relatively simple to spot gtk/gdk drawing problems. Now, it's difficult to say where the problems are, given the gtk-cairo-exa-newX stack. For people interested, there is a good discussion in a now-closed bug that addresses some of the slow drawing issues, which I think at this point are history: http://bugzilla.gnome.org/show_bug.cgi?id=314616 But I wonder if the relevant functions don't need to be revisited? Does anyone have any suggestions on how to profile these issues? --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
James Livingston wrote: On Tue, 2006-01-31 at 14:38 +, Thomas Wood wrote: This isn't really the issue. The problem is that the apply procedure takes more than a second to complete, thus violating the previously mentioned section of the HIG about instant apply. I saw a figure quoted that the average time to apply was 1.4 seconds. How did that get evaluated? The machine I'm on at the moment isn't old, but it definitely isn't that new either, and it takes under half a second to change the background. I was talking about the theme manager, and asking whether it should also be switched to explicit apply. If you could time how long it takes to apply a theme on your machine, that would be a useful figure to have. One thing I noticed is that the time is greatly affected by whether Nautilus is drawing the desktop or not. I normally don't, but when turned on the time was up to around a second. Drawing the icons and text might take extra time, but is there something Nautilus is doing that causes it to go that much slower? Cheers, James Doc Livingston ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
Le mardi 31 janvier 2006 à 10:14 -0500, Owen Taylor a écrit : On Tue, 2006-01-31 at 09:16 -0500, Pat Suwalski wrote: James Henstridge wrote: If this is the case, has anyone pinged Carl Worth about the slowdown, to see if it can be fixed? (either on our end by doing the rendering in a more efficient way, or by adding fast paths to Cairo for the particular calls). I wonder if it would make sense to implement the same technique as eog uses, with a first rough-pass for a very fast application, and a better pass when it becomes available? That's only necessary when we can't make it fast enough to begin with! :-) I think the first step is for someone to simply spend a little time figuring out what is slow: - Gradients - Scaled images - Solid color backgrounds? If we are scaling images *via Cairo* that is known to be slow with older X servers; if investigation proves that actually is the problem, it can be worked around. I think the problem most people are encountering are with scaled images, see https://bugs.freedesktop.org/show_bug.cgi?id=4320 . The only way I found for Mandriva 2006 to ship with decent performance was to always force cairo to use XCopyArea instead of XRenderComposite -- Frederic Crozat [EMAIL PROTECTED] Mandriva ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
James Livingston wrote: One thing I noticed is that the time is greatly affected by whether Nautilus is drawing the desktop or not. I normally don't, but when turned on the time was up to around a second. Drawing the icons and text might take extra time, but is there something Nautilus is doing that causes it to go that much slower? BINGO. This narrows in on the culprit. Disabling show_desktop makes the whole desktop 3-4 times more snappy, especially with EXA. It appears that (at least with radeon), nautilus' desktop drawing breaks very drastically. But even with top-of-the-line nVidia (with closed driver), desktop scaling speed is very much improved without nautilus. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
On Tue, 2006-01-31 at 10:49 -0600, Federico Mena Quintero wrote: On Tue, 2006-01-31 at 10:14 -0500, Owen Taylor wrote: I think the first step is for someone to simply spend a little time figuring out what is slow: - Gradients - Scaled images - Solid color backgrounds? If we are scaling images *via Cairo* that is known to be slow with older X servers; if investigation proves that actually is the problem, it can be worked around. I'm pretty sure that this is the same bug as https://bugs.freedesktop.org/show_bug.cgi?id=4320 At Suse we have Stefan Dirsch looking into that particular bug. This may help the capplet, but again, someone needs to profile the capplet to see what is going on. Federico Profiling the capplet won't help at all. It's not actually doing any of the drawing on the desktop. Someone needs to profile nautilus and/or the gnome-settings-daemon processes. These are the places where the drawing happens. Albeit much faster without nautilus running, it could probably still stand to see a little bit of improvement. A quick test by quickly changing some background images on my old Powerbook G3 (400 w/192 MB RAM, on OS 10.2), showed that it still seemd a bit faster than we are, even without nautilus managing the desktop. -- dobey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
On Tue, 2006-01-31 at 12:39 -0500, Pat Suwalski wrote: James Livingston wrote: One thing I noticed is that the time is greatly affected by whether Nautilus is drawing the desktop or not. I normally don't, but when turned on the time was up to around a second. Drawing the icons and text might take extra time, but is there something Nautilus is doing that causes it to go that much slower? BINGO. This narrows in on the culprit. Disabling show_desktop makes the whole desktop 3-4 times more snappy, especially with EXA. It appears that (at least with radeon), nautilus' desktop drawing breaks very drastically. But even with top-of-the-line nVidia (with closed driver), desktop scaling speed is very much improved without nautilus. This is actually not surprising at all. The desktop background is computed twice - once by (IIRC) gnome-settings-daemon and once by nautilus. gnome-settings-daemon modifies the actual root window, and also a pixmap pointed to from a root window property, so: - If nautilus isn't running or is killed, or whatever, you still have a background. - Transparent terminals and other hacks that need to access the root window image can get the pixmap. But nautilus is covering up g-s-d's work, so it has to compute and draw the desktop as well. So if things roughly double in speed when you disable nautilus, this is about what is expected. Regards, Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Performance (was Re: control-center 2.13.90 released)
Jan de Groot wrote: On Tue, 2006-01-31 at 15:31 +, Thomas Wood wrote: It'd be interesting if you could try changing your theme (I assume you are using Clearlooks) to Glider and seeing what difference that makes. The Glider theme uses the Smooth engine, which is not currently using cairo. Clearlooks on the other hand, is now using cairo almost exclusively. If there is a significant difference in speed then we may need to look at holding back cairo enabled gtk-engines in GNOME, at least until significant speed improvements are made to cairo. -Thomas I switched back from Clearlooks cairo version to the Mist theme: everything is nice and fast now. With cairo-clearlooks, clicking a cleared number in gnome-mines, I could follow the bombsquad clearing the field of known not-mine squares. With Mist, these fields get uncovered instantly. Actually, Mist is already using cairo, so your test only shows that Mist is a faster theme than Clearlooks. This was hopefully already known, since Mist is a lot simpler than Clearlooks. One of the biggest problems for Clearlooks in terms of speed, is it's use of gradients, and that has always been an issue whether it has used GDK or cairo. To get a definitive answer, we need people to test is the difference between using Clearlooks with cairo (gtk-engines 2.7.x) and with GDK (gtk-engines 2.6.x). -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Performance (was Re: control-center 2.13.90 released)
On Tue, 2006-01-31 at 21:05 +, Thomas Wood wrote: I switched back from Clearlooks cairo version to the Mist theme: everything is nice and fast now. With cairo-clearlooks, clicking a cleared number in gnome-mines, I could follow the bombsquad clearing the field of known not-mine squares. With Mist, these fields get uncovered instantly. Actually, Mist is already using cairo, so your test only shows that Mist is a faster theme than Clearlooks. This was hopefully already known, since Mist is a lot simpler than Clearlooks. One of the biggest problems for Clearlooks in terms of speed, is it's use of gradients, and that has always been an issue whether it has used GDK or cairo. To get a definitive answer, we need people to test is the difference between using Clearlooks with cairo (gtk-engines 2.7.x) and with GDK (gtk-engines 2.6.x). -Thomas Actually, together with switching to Mist, I also switched back to the old GDK version of gtk-engines. I will try some tests with gtk-engines 2.7.x tomorrow to see if there's a noticable speed difference. For the clearlooks themes with cairo: having a card that does RENDER accelleration can speed up quite a lot. Switching from a Matrox G550 to a Radeon 8500LE really shows good results for cairo. But I guess we should also think about those people who still have hardware that does not support render accelleration that much (I have X terminals with 4MB Matrox Millennium cards in them, they're terrible slow since the switch to GTK 2.8) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
Owen Taylor wrote: So if things roughly double in speed when you disable nautilus, this is about what is expected. Perhaps this is one of those lovely O^2 operations or something, but it's a transition from about 30 fps to about 1 fps. There is almost certainly more to it --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
On Tue, 2006-01-31 at 15:08 -0500, Rodney Dawes wrote: Profiling the capplet won't help at all. It's not actually doing any of the drawing on the desktop. Someone needs to profile nautilus and/or the gnome-settings-daemon processes. These are the places where the drawing happens. Albeit much faster without nautilus running, it could probably still stand to see a little bit of improvement. A quick test by quickly changing some background images on my old Powerbook G3 (400 w/192 MB RAM, on OS 10.2), showed that it still seemd a bit faster than we are, even without nautilus managing the desktop. Okay, so let's profile all the parts involved to see where the problem is. Can you build the whole gnome-control-center module with no inlining and debug info (-O2 -fno-inline works well), and then run sysprof while changing backgrounds quickly? Do that with and without nautilus running. As far as I know, we have two main slow paths: 1. Nautilus redrawing its background. It doesn't do anything special; it just sets the desktop window's background to the pixmap that g-s-d maintains; then it does gtk_widget_queue_draw() on the desktop window. This goes through the normal double-buffering code in GTK+. The test code here does exactly what Nautilus does: https://bugs.freedesktop.org/show_bug.cgi?id=4320#c3 2. G-s-d generating a new background pixmap. This is the create-a-pixmap, paint-a-gradient, scale-an-image thing. No idea if this is slow, but it certainly doesn't need to be. Running sysprof on the whole stack will tell you who is at fault. It would be good to know how much time (2) takes. Stick printf()s at the beginning and end of the change-the-background process in g-s-d, and make them print timestamps. Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
On Tue, Jan 31, 2006 at 08:58:22AM -0500, Rodney Dawes wrote: On Tue, 2006-01-31 at 12:49 +, Calum Benson wrote: On Mon, 2006-01-30 at 13:52 -0700, Elijah Newren wrote: I also feel that it looks odd and out of place (Why else would I click on a different image than to have it be my background?). It appears this was done because the change was too slow -- at least that's the valid reason I could find at http://bugzilla.gnome.org/show_bug.cgi?id=327335. I'm with Federico though in thinking we should make it fast instead. And in the meantime, a bit of pointer feedback would probably relieve any why is nothing happening? symptoms on the instant-apply front. The gnome-background-properties dialog has no idea how long it will actually take for the settings to take effect, as it does not control the actual drawing on the background. The gconf calls to set the keys succeed and return instantly, which means that changing the pointer in the capplet itself, based on that information, would be totally useless. A timeout would still be needed, to slow the UI down. At this stage in the game, I think we should look at doing three things: (1) reverting the UI change, it is a bandaid fix to a deeper problem; (2) shipping GNOME 2.14 with gtk-engines 2.6, leaving people who giving us more time to optimise gtk-engines/cairo/X (3) attempting to profile Nautilus and find out why it is that little bit slower It will be absolutely appaulling if we ship Cairo based gtk-engines (which most people will not appreciate) while claiming that we've sped up all these things (pango, GSlice, etc.) only to have all of our actual window drawing shot to pieces. Once we're on 2.15, we can start using the new gtk-engines again, hopefully with Cairo 1.2 and start looking at what is making it slow (still). People have suggested adding D-BUS interfaces to Nautilus to know when the background is done being changed, but I think this is also unrequired. We obviously have a fast code path and a slow code path, and there has to be a logical explanation for this. If it is unfixable, then perhaps D-BUS should be our bandaid. --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
On 1/30/06, Rodrigo Moya [EMAIL PROTECTED] wrote: Changes since 2.13.5.1 background: - Added apply button (Rodney Dawes) (327335) - Fixed glib CRITICAL warnings (Rodney Dawes) (327327) So, Gnome 2.12 had a nice working immediate apply background changer. Why did this get changed to an odd explicit model ? Thats a step backwards. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
Em Seg, 2006-01-30 às 15:06 -0500, Matthias Clasen escreveu: On 1/30/06, Rodrigo Moya [EMAIL PROTECTED] wrote: Changes since 2.13.5.1 background: - Added apply button (Rodney Dawes) (327335) - Fixed glib CRITICAL warnings (Rodney Dawes) (327327) So, Gnome 2.12 had a nice working immediate apply background changer. Why did this get changed to an odd explicit model ? Thats a step backwards. I think it was done to follow the HIG: http://developer.gnome.org/projects/gup/hig/2.0/windows-utility.html#windows-instant-apply Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
On 1/30/06, Matthias Clasen [EMAIL PROTECTED] wrote: On 1/30/06, Rodrigo Moya [EMAIL PROTECTED] wrote: Changes since 2.13.5.1 background: - Added apply button (Rodney Dawes) (327335) - Fixed glib CRITICAL warnings (Rodney Dawes) (327327) So, Gnome 2.12 had a nice working immediate apply background changer. Why did this get changed to an odd explicit model ? Thats a step backwards. I also feel that it looks odd and out of place (Why else would I click on a different image than to have it be my background?). It appears this was done because the change was too slow -- at least that's the valid reason I could find at http://bugzilla.gnome.org/show_bug.cgi?id=327335. I'm with Federico though in thinking we should make it fast instead. Anyway, just my $0.02. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
Elijah Newren wrote: http://bugzilla.gnome.org/show_bug.cgi?id=327335. I'm with Federico though in thinking we should make it fast instead. If memory serves, the background resampling and applying used to be very snappy and got significantly slower when everything moved to cairo. At this point, I have the X hashed background until a few seconds after my panels show up. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
On Mon, 2006-01-30 at 13:54 -0700, Elijah Newren wrote: It's worth noting that the only applicable reason from that page for not making it instant apply is that it took longer than a second. It's worth noting that several have commented in http://bugzilla.gnome.org/show_bug.cgi?id=327335 saying that we should look at making it faster, since it's close to a second (and for several people is faster than a second) anyway. For those of us for whom it is faster than a second, this change is a HIG violation AFAICT. No, read my mail to announce the changes to the appropriate lists. Both reasons are valid. All of the settings in the dialog get applied at the same time as well. So, the HIG still suggests it should be explicit apply, even if it is fast for you. It was done to follow these two suggestions in the HIG, as well as to help address users experience confusion with the Close button, as was discovered in some of the usability tests we conducted for BetterDesktop. The Close button, ironically, did not give several of the users in the tests, the feeling of closure. I'd have to go through the videos again, to see which ones that are on the site, and stated this, though. I should be able to do that soon to answer that question if it's now dwelling in the back of your head, as well as to answer Bryan asking it in the bug report you mention. -- dobey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
On 1/30/06, Rodney Dawes [EMAIL PROTECTED] wrote: On Mon, 2006-01-30 at 13:54 -0700, Elijah Newren wrote: It's worth noting that the only applicable reason from that page for not making it instant apply is that it took longer than a second. It's worth noting that several have commented in http://bugzilla.gnome.org/show_bug.cgi?id=327335 saying that we should look at making it faster, since it's close to a second (and for several people is faster than a second) anyway. For those of us for whom it is faster than a second, this change is a HIG violation AFAICT. No, read my mail to announce the changes to the appropriate lists. Both reasons are valid. All of the settings in the dialog get applied at the same time as well. So, the HIG still suggests it should be explicit apply, even if it is fast for you. Could you explain the reasoning? I've read your announcement (you're referring to the one to gnome-doc-list and gnome-i18n list, right? I'm not aware of any other) and the HIG page and things don't seem to jive: From your announcement: 'The changing of one's background takes 1.4 seconds on average, with Nautilus managing the background, and all of the settings need to be applied at the same time, which means that the dialog meets both exceptions as stated in the Instant apply windows section.' vs the HIG: 'Do not make the user press an OK or Apply button to make the changes happen, unless either: * the change will take more than about one second to apply, in which case applying the change immediately could make the system feel slow or unresponsive, or * the changes in the window have to be applied simultaneously to prevent the system entering a potentially unstable state. For example, the hostname and proxy fields in a network properties window.' I can understand the timing one (though that just sounds like a bug that needs to be fixed; it was fast before as Pat points out), but I don't remotely see how the background preferences settings can be put into an inconsistent/unstable state with instant apply. I could just be missing something obvious, though. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
