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

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

2006/10/9, Carl Worth <cworth cworth org>:
> On Mon, 9 Oct 2006 07:56:27 +0300, "Kalle Vahlman" wrote:
> >
> > gtk_marshal_BOOLEAN__BOXED         0,03  46,28
> >   gtk_button_expose                 0,03  24,88
> >   scw_view_expose                   0,00   8,96
> > ...
> ...
> > 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
>
> We've only got relative percentages to work with, which isn't a lot
> here, but let's try. If we assume that the scw_view_expose time is
> independent of the tessellator, (which is perhaps unlikely), then we
> can say that gtk_button_expose is about 2.8 times slower than it with
> the new tessellator and roughly the same speed with the old
> tessellator.

I just realized that when I zoomed in for the tesselator it of course
changed the numbers to be global, so they can be discarded as
non-informative straight away. I was way off target with those.

> So there is probably a tessellator slowdown here. Is this on a no-FPU
> machine? The 4x improvement I saw, (which was really just one number
> from one test case---not necessarily representative, etc. etc.), was
> on an x86 laptop.

Yeah, but that was my concern too :)
(that the code was good for non-realistic case but not for real)

And this is a x86 laptop too, a slowish one though (by todays
standards, 700MHz Celeron).

> If the algorithmic improvements are all correct then the new
> tessellator should be doing fewer intersection computations than the
> old one. It might actually be interesting for you to throw a counter
> into _line_segs_intersect_ceil (for old---and careful to not
> instrument the first instance which is not compiled dues to a "#if
> 0"), and _cairo_bo_edge_intersect (for the new tessellator). That
> would let us see if the algorithmic stuff is working correctly.

Have to try that out when I get some free time.

> Meanwhile, I'd still be interested in a higher-level view of what's
> happening here. Why is the tessellator such an significant aspect of
> drawing a button? What kinds of cairo operations is ClearLooks doing
> here?
>
> On that topic, here is a cairo performance bug that Benjamin
> identified for me this week (other theme authors reported having the
> same problem):
>
>  * Using cairo_stroke to draw a single-pixel rectangle is much slower
>    than using cairo_fill to draw exactly the same thing.

Tested this with torturer and drawing the button as a rounded
rectangle with either fill or stroke. And indeed there is a noticeable
difference, although the resize value is about the same. Perhaps the
fill is transferring more data or something.

Fill:
# Widget        Expose   Resize
GtkButton       0,00457741       0,0415327

Stroke:
# Widget        Expose   Resize
GtkButton       0,00535777       0,0417463

Interesting stuff in any case.

Fortunately I have a week of vacation coming up, so I can dig in some
more in this profiling stuff... This is fun :)

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