2006/10/9, Carl Worth <[EMAIL PROTECTED]>: > 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, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi _______________________________________________ Performance-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/performance-list
