Re: control-center 2.13.90 released

[Rodney Dawes <dobey novell com>]

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

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. And the oversimplification of the problems into "i think it's
ugly, so we shouldn't do this" is just silly. The change was not done
solely to work around the performance issue. Any claims that it was, are
obviously misinformed and oversimplifying the set of problems that the
change was meant to solve.

> 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.

-- dobey