Re: --gtk-unbuffered

[Owen Taylor <otaylor redhat com>]

Hans Breuer <hans breuer org> writes:

> Hi Owen, et. al,
> while trying to further identify the performance bottlenecks
> in current gtk+, I've added a runtime switch to globally
> disable double buffering. (See patch below, ok to commit ?).

Not OK. Double buffering changes the semantics, it's not just
some cosmetic tweak.

If double buffering is a major performance bottleneck on windows,
something is wrong.

What are you trying to achieve by turning off double buffering?

> The slowest parts - compared to the times before Pango / GObject / 
> Backing Store merge are:
> 
> testgtk::message dialog :
> testgtk::labels : the "normal" text rendering is relatively ok, but
> 	the rendering of auto-wrapped labels is at least twenty times
> 	slower than before. While investigating possible sollutions
> 	I stumbled over three functions, which all say something
> 	about required optimization :
> 
> 	gtk_label_ensure_layout - probably called more often than needed
> 
> 	pango_layout_set_width ->
> 	pango_layout_clear_lines : (called too often)
> 		/* This could be handled separately, since we don't need to
>        	* recompute log_attrs on a width change, but this is easiest
>        	*/
> 	pango_layout_get_extents(_internal) ->
> 	pango_layout_check_lines - 
> 
> The sequence in gtk_label_ensure_layout () calls set_with and get_extents
> up to five times, which cause the pango internal log_attrs to be destroyed
> and recalculated constantly although the comment above says, that it would
> not be necessary to do it at all, on a width change.
> 
> I'm afraid, that I don't understand pango internals enough to fix this myself.
> Could someone please take a look into it ?

How are you measuring performance? "20 times slower" is not really
a useful statement. 

If the original took 0.1 milliseconds, then do we care? Almost
certainly not. If the original took 0.1 seconds, then we would
care.

GtkLabel uses a quite inefficient algorithm for figuring out the
requested size, which involves repeatedly re-laying out the
text at different widths.

But, it's not worth trying to fix this algorithm unless it actually
produces _noticeably_ bad performance, especially since a fix
would involve considerable increases in complexity.
 
> testgtk::color selection :
> 	has a slightly unoptimized implementation, constantly recalculating 
> 	masks etc. The Gimp color selctor shows, how much faster this could
> 	be done, even on windoze :) Would a patch to improve performance be
> 	considered for imclusion ?

It's not noticeably slow on on Unix. So, it's probably revealing
some problem in the Windows backend.

Now, of course, some things may just be inherently slow/ineffecient
with Win32 GDI, but I generally wouldn't expect a large difference.

A patch that increases performance, would be be accepted if:
 
 - It made sense
 - It was clean code

But I think it would be worth quantifying the things that are
slow on windows as compared to Unix, so we can either fix
them or code around them. When I code for X, the cardinal
rule is "avoid round trips to the server", and if you do
that, you can be astoundingly inefficient and still get
decent performance.

But I don't have much of a sense of what's going on with
performance and the Win32 port.
 
> testgtk::file selection : (takes some seconds to show up in the gtk build
> 	directory)
> 	requires further investigation. My current guess is, that the
> 	whole file lists gets caculated (and rendered?) before showing
> 	the dialog.

No, that's not it. And it is, again, not noticeably slow on
Unix.

Regards,
                                        Owen