Re: Some initial thoughts about 2.4

[Owen Taylor <otaylor redhat com>]

Biswapesh Chattopadhyay <biswapesh_chatterjee tcscal co in> writes:

> <snip>
> 
> > Possible features: [off the top of my head]
> > 
> >  - File selector (we have to get this one)
> >  - Combo widget (Kris has made progress here)
> >  - New action-based menu API (based on James Henstridge's work, most
> >  likely)
> >  - Toolbar improvements
> >  - GObject private data
> >  - Full Unicode 3.2 (4.0?) support, including non-BMP portions.
> >  - GtkModelFilter (Pretty much done in libegg)
> >  - Make RTL text editing really work (automatic paragraph
> >    direction, etc.)
> >  - Height-for-width geometry management. (Define a new interface,
> >    support it GtkVBox, GtkLabel woudl be the minimum.)
> > 
> 
> How about performance and footprint improvement ?
> 
> GTK2 seems substantially slower and heavier than GTK1 on my machine.
> This is obviously not a settings problem since quite a few others have
> been saying the same thing on gnomedesktop.org and other places.

GTK2 *is* substantially slower and heavier than GTK1 in some aspects. 
This is because:

 - It has zillions of new features
 - It draws more prettily and smoothly

I think it would be a real shame if GTK+ was frozen at the level
of features that it got when we were developing on a 100mhz, 32meg
machines.

That isn't to say that performance of the current feature set 
can't be improved. If someone shows up with a:

 * Benchmark and profile of the benchmark that shows where GTK+ is slow
 * A patch to fix it

We'd love the contribution. 

But "Make GTK+ faster" shouldn't be on the 2.4 feature list because
it doesn't actually indicate any particular action. There are
various performance related improvements that can be done that
I know of.
 
 - GObject could be made 20-30% faster by careful code optimization
 - fontconfig startup times could be substantially improved
   with some optimization
 - Caching of scratch GC's inside GDK might improve things a bit,
   though I've never seen evidence on profiles that GC creation
   destruction is a major factor.
 - There are some improvements that can be made to 
   gdk_window_invalidate_region() (which shows up high on some
   profiles)

These are things that I've noted from spending weeks studying profiles
of GTK+ and are generally reasonably major projects. The stuff that
was easy to do and produced big improvements has been done.

I'd expect the overall improvement from implementing the above to 
be order 10% ... I don't think it would be possible to make GTK+ 
50% faster without major feature removal. (Please prove me wrong ...) 

On the other hand, machines double in speed, both on the high and low
end, every year or two, so GTK+ will be twice as fast soon enough.

A lot of the easiest ways to improve GTK+ performance are outside
of GTK+:

 - Implement object file reordering for Linux
 - Work on optimization of RENDER inside the X server

After the pixops improvements that have been in bugzilla for a 
long time, if my interest was overall toolkit speed, these would
be the areas I'd be looking at first.

Regards,
                                        Owen