Re: Gtk performance issues from a user's point of view

["Kalle Vahlman" <kalle vahlman gmail com>]

2006/10/9, Federico Mena Quintero <federico ximian com>:
> On Mon, 2006-10-09 at 07:56 +0300, Kalle Vahlman wrote:
>
> [old percentage for gtk_button_expose() was 24.88%]
> > The new tesselator was supposed to be up to four times faster than the
> > old one, but running the same test with the old one yields a different
> > result:
> >
> > _gtk_marshal_BOOLEAN__BOXED         0,05  33,43
> >   gtk_button_expose                 0,00  10,91
> >   scw_view_expose                   0,02  10,13
> >   gtk_label_expose                  0,00   3,54
> >   meta_frames_expose_event          0,00   3,16
> >
> > also the path to tesselation seem very different, but that's probably
> > to be expeceted...
> >
> > So, now I toss the ball to Carl's corner; am I misinterpeting or is it
> > a regression in the tesselator? Do the traces look plausible?
>
> ... But this is giving you percentages (did you expect 6%?), not
> absolute timings.

Sure, but I was basing the argument in the differences of the widgets,
not percentages themselves. I really would expect ScwView to be slower
than the buttons given that it fills up most of the screen while the
buttons only stretch horizontally (though, I hadn't considered the
per-widget overhead drawing generates for the buttons so I was perhaps
expecting too fast in my mind...). The widget is not cabable of
drawing partial rows, and it has no caching system apart from that of
pango. Maybe Behdad is actually even cooler guy than I thought ;) but
I was expecting it to be dog slow. And in particluar, slower than the
buttons (which it doesn't seem to be).

What I really wanted to ask from Carl is more like "is it expected
that those certain functions are hit so much while the old tesselator
profile is more spread" instead of "why is it so slow" (as I realize
it might sound).

>  Manu's theme torturer may give you more useful
> numbers here - it actually gives you timings.
>
> In particular, the torturer makes it easy to plug arbitrary widgets and
> get timings when they are exposed/resized/etc.  You may want to plug
> your whole complex window and see what it tells you.

Yeah, that's the next step I guess.

> > But the second expose pair shows something which feels to me as a
> > mistake. The first expose is for the new area of the window. This
> > makes a full redraw in my test case anyway, even if the clipping mask
> > is set. The second is for the full window area, which of course means
> > we'll draw it again making the first draw totally unneccesary.
> >
> > I'm guessing this is so (assuming it's intentional) in order to make
> > the empty space fill up faster and only after that fill the rest. But
> > then it would make sense to get the later expose only to the part that
> > wasn't already updated, not to the whole widget.
> >
> > And if you think about it, how many widgets actually are cabable of
> > drawing like that without drawing the whole thing twice?
>
> If your widget is smart enough, you may want to experiment with
> gtk_widget_set_redraw_on_allocate(w, FALSE).  When the widget gets
> resized, that will give you expose events only for the new area, not for
> the old one.

That would really help ScwView only when resizing vertically I'm afraid.

I guess the partial expose on configure will be beneficial when some
widgets happen to be in the old window area after the resize and keep
their sizes intact.

But what needs to be determined is that does it yield a bigger benefit
than what avoiding the extra work for widgets that can't avoid it? Mr.
Vire reminded me today about the ExposeEvent->count that tells how
many expose events are queued. That might give some help here for
costly widgets, though collapsing those events sounds like something
GTK+ should be doing anyway (and probably is). Need to check that too.

--
Kalle Vahlman, zuh iki fi
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi