[cairo] Re: Gtk performance issues from a user's point of view
kalle.vahlman at gmail.com
Thu Oct 12 13:15:06 PDT 2006
2006/10/9, Carl Worth <cworth at 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
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
> 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.
# Widget Expose Resize
GtkButton 0,00457741 0,0415327
# 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 at iki.fi
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi
More information about the cairo