Re: Gtk performance issues from a user's point of view
- From: Federico Mena Quintero <federico ximian com>
- To: zuh iki fi
- Cc: cairo cairographics org, Performance-list gnome org
- Subject: Re: Gtk performance issues from a user's point of view
- Date: Mon, 09 Oct 2006 10:12:21 -0500
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. 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.
> 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.
Federico
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]