headers
Glynn Foster | 1 Feb 2006 04:04
Picon

Re: control-center 2.13.90 released

Hi,

On Tue, 2006-01-31 at 17:11 -0600, Federico Mena Quintero wrote:
> 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?

Changing backgrounds quickly doesn't really help, since
XSetWindowBackgroundPixmap() isn't being called each time, at least when
nautilus has been disabled [I'm only checking that case right now] - or
that's what I'm seeing while using DTrace.

Also, the default set of backgrounds have completely different sizes and
types as a quick browse through /usr/share/pixmaps/backgrounds will
show. It might be cunning to pick one relatively plain background,
duplicate it a couple of times and change the colour of it, then edit
the xml files in /usr/share/gnome-background-properties for different
wallpaper options.

I'm also not really noticing the slowness that people are experiencing,
or at least background changing seems reasonably responsive - this may
be due to some cairo patches that we've applied locally, I'm not sure.

Glynn
Permalink | Reply | 18 comments |
headers
Federico Mena Quintero | 1 Feb 2006 19:04

Re: control-center 2.13.90 released

On Wed, 2006-02-01 at 16:04 +1300, Glynn Foster wrote:

> Changing backgrounds quickly doesn't really help, since
> XSetWindowBackgroundPixmap() isn't being called each time, at least when
> nautilus has been disabled [I'm only checking that case right now] - or
> that's what I'm seeing while using DTrace.

What does "each time" represent here?  Each time you select a different
wallpaper, or change an option (gradient/color/etc)?

> Also, the default set of backgrounds have completely different sizes and
> types as a quick browse through /usr/share/pixmaps/backgrounds will
> show. It might be cunning to pick one relatively plain background,
> duplicate it a couple of times and change the colour of it, then edit
> the xml files in /usr/share/gnome-background-properties for different
> wallpaper options.

Let's use the real-world data we have, that is, the real stuff
in /usr/share/pixmaps/backgrounds.

I'm interested in knowing

- how long do we take to load the image from disk and decode it.  For a
1400x1050 JPEG, this takes 0.27 seconds for me from looking at strace.

- how long do we take to generate the pixmap we set on the root window,
based on the decoded pixbuf.  No idea how long that takes.  Test the
various cases:  this is the cross product of { solid image, image with
alpha} x { solid color, gradient } x { tiled/untiled image covers the
background completely, background shows through }.  libbackground has
(Continue reading)

Permalink | Reply | 17 comments |
headers
Kjartan Maraas | 1 Feb 2006 18:33
Picon
Favicon

Re: control-center 2.13.90 released

man, 30,.01.2006 kl. 13.52 -0700, skrev Elijah Newren:
> On 1/30/06, Matthias Clasen <matthias.clasen <at> gmail.com> wrote:
> > On 1/30/06, Rodrigo Moya <rodrigo <at> gnome-db.org> 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.
> 
I agree with this sentiment too. The old one both looks better and feels
better. What's the rationale for removing the icons on the buttons etc
btw?

Cheers
Kjartan
Permalink | Reply | 0 comments |
headers
Alan Horkan | 1 Feb 2006 18:49
Picon
Picon
Favicon

Re: control-center 2.13.90 released


> From: Davyd Madeley <davyd <at> madeley.id.au>
> To: Rodney Dawes <dobey <at> novell.com>
> Cc: Desktop Development List <desktop-devel-list <at> gnome.org>,
>      Calum Benson <Calum.Benson <at> Sun.COM>
> Subject: 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 +0000, 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:
(Continue reading)

Permalink | Reply | 8 comments |
headers
Shaun McCance | 2 Feb 2006 01:27
Picon
Gravatar

Re: control-center 2.13.90 released

On Wed, 2006-02-01 at 17:49 +0000, Alan Horkan wrote:
> > From: Davyd Madeley <davyd <at> madeley.id.au>
> > 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.

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.

--
Shaun
(Continue reading)

Permalink | Reply | 3 comments |
headers
Federico Mena Quintero | 2 Feb 2006 04:00

libgnomeui branched to libgnomeui-2-14

Hi,

I just branched libgnomeui for GNOME 2.14.

2.14 will use the libgnomeui-2-14 branch; it is anchored on the tag
LIBGNOMEUI_2_14_BRANCHPOINT.  I just updated the moduleset in jhbuild
for this; make sure you update your jhbuild to get this info.

Development goes on in HEAD as usual.

  Federico
Permalink | Reply | 10 comments |
headers
Danilo Šegan | 2 Feb 2006 00:33
Picon
Gravatar

Re: CVS conflicts for po files in doc directories

On Tuesday at 21:16, Shaun McCance wrote:

> And Danilo, that reminds me, we *really* need to get some sort of
> sans-autogen sans-make method of updating documentation po files
> into gnome-doc-utils/xml2po in the next release cycle.  I'm sure
> translators are sick of me forcing them to do full checkouts and
> actually build the software.

Agreed.  In most cases it's easy to work-out that (if a maintainer
isn't using too complex scheme to construct variables to be passed to
gnome-doc-utils.make stuff). 

But, we already have some similar rules for that in intltool? Or do we
want to tell maintainers to be a bit more restricted with it ;)

And I have something in my l10n-doc-status scripts as well (in Python)
that can work out the simpler cases.

Cheers,
Danilo
Permalink | Reply | 0 comments |
headers
Rodney Dawes | 2 Feb 2006 15:23
Picon
Favicon

Re: control-center 2.13.90 released

On Wed, 2006-02-01 at 17:49 +0000, Alan Horkan wrote:
> > From: Davyd Madeley <davyd <at> madeley.id.au>
> > To: Rodney Dawes <dobey <at> novell.com>
> > Cc: Desktop Development List <desktop-devel-list <at> gnome.org>,
> >      Calum Benson <Calum.Benson <at> Sun.COM>
> > Subject: 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 +0000, 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:
(Continue reading)

Permalink | Reply | 3 comments |
headers
Iain * | 3 Feb 2006 00:39
Picon

Re: control-center 2.13.90 released

On 2/1/06, Federico Mena Quintero <federico <at> ximian.com> 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
Permalink | Reply | 4 comments |
headers
Davyd Madeley | 3 Feb 2006 00:55
Picon

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.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane