On 7/13/06, Federico Mena Quintero <[EMAIL PROTECTED]> wrote: > On Thu, 2006-07-13 at 09:01 -0500, Matt Hoosier wrote: > > > I've done a little bit of benchmarking using the attached program (be > > This program makes the same mistake as gtk-perf: it sends the drawing > requests, but doesn't wait for the X server to actually perform them. > So you are essentially profiling Cairo and Xlib. You aren't seeing > things like "the X server takes 50% of the CPU time while the benchmark > is running".
Thanks for taking a look at the program. > > If you download the gtk+ sources, check out > gtk+/perf/gtkwidgetprofiler.h. It has the machinery needed to wait for > the server to actually process your requests. Okay, done. After some refactoring a little bit (e.g., remove the idle function which was driving the redrawing -- gtkwidgetprofiler's harness already calls triggers expose events anyway ), I get the following: before patches: 0.0170269 sec average over 200 expose handler invocations after patches: 0.0134765 sec average over 200 expose handler invocations This is roughly the same ratio as when the drawing was done (before) asynchronously. > > Manu Cornet (on the CC line) is my student for the Summer of Code, and > he's writing a torture test for theme engines that uses > GtkWidgetProfiler appropriately. This can be used both as a benchmark, > and also a way to ensure the robustness of theme engines. > > Federico > > _______________________________________________ Performance-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/performance-list
