Thanks very much for looking at this John I didn't get nearly that dramatic of a speedup, maybe 2x. I get about this same result on a 1Ghz Via machine w/ openchrome on cx700 (2x speedup) The funny thing is, using event boxes with pixmaps like the javascript uses also results in a fairly slow update. Maybe I am loading the pixmaps incorrectly or something. There has to be a way to optimize this since there is no rendering. I'll send you example code doing this in a later update. I think there is room for some optimization here considering firefox does the same thing but faster. Here are my stats for 10 clicks in Redmond $ time ./main real 0m4.739s user 0m0.700s sys 0m0.070s Here are my stats for 10 clicks in Ambiance $ time ./main real 0m11.299s user 0m1.420s sys 0m0.130s Its funny that it says 1.42 seconds, but I wait until the screen is updated before I click (~0.4 seconds). I have an Intel Core 2 duo and Intel Graphics card. It may be a 10x speedup in actuality because it takes a long time for the gui to actually update and time may be wrong or I am interpreting it wrong. Here is my oprofile results: $opreport -a -l -g CPU: Core 2, speed 1200 MHz (estimated) Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000 samples cum. samples % cum. % linenr info image name app name symbol name 21814 21814 15.1615 15.1615 (no location information) libc-2.11.1.so libc-2.11.1.so /lib/libc-2.11.1.so 19012 40826 13.2140 28.3754 (no location information) libpixman-1.so.0.16.4 libpixman-1.so.0.16.4 /usr/lib/libpixman-1.so.0.16.4 17866 58692 12.4175 40.7929 (no location information) libcairo.so.2.10800.10 libcairo.so.2.10800.10 /usr/lib/libcairo.so.2.10800.10 12673 71365 8.8082 49.6011 (no location information) libglib-2.0.so.0.2400.1 libglib-2.0.so.0.2400.1 /lib/libglib-2.0.so.0.2400.1 9810 81175 6.8183 56.4193 (no location information) Xorg Xorg /usr/bin/Xorg On Mon, Jan 3, 2011 at 6:01 PM, <jcupitt@xxxxxxxxx> wrote: > On 3 January 2011 21:51, Brian Phelps <lm317t@xxxxxxxxx> wrote: >> I tried the plain default theme BTW and it made no discernable >> difference in speed to the GTK/C implementation. > > I tried here and on a Ubuntu 10.10 install on a recent macbook with > the Ambiance theme your example was rather slow. There was an > appreciable delay (0.5s? something like that) between pressing the > top-left button and the display updating. > > I tried running under callgrind and it does seem to be spending a lot > of time somewhere deep inside libcairo (the graphics library that gtk > uses to draw the screen). I don't have a dbg version of cairo handy to > dig deeper. > > If I run with "time" and press the toggle button 10 times, I get: > > $ time ./main > real 0m18.022s > user 0m5.040s > sys 0m0.300s > > I installed the gnome-themes-extra package, plus a thing called > gtk-theme-switch, and swapped to the "redmond" theme. This is just > hideous (a win95 lookalike) but does use very simple drawing > operations to display the widgets. With the redmond theme, display > updates are instant (or seem to be). > > For 10 button presses I get: > > $ time ./main > real 0m13.190s > user 0m0.360s > sys 0m0.060s > > So, more than 10 times faster. Brian, have you tried a simple theme > like this (ugly square buttons, no gradients)? > > Comparing a browser to gtk is perhaps a little unfair. This test is > spending almost all its time in the graphics library, not in gtk, so > you are really comparing the speed at which a browser can display > bitmaps (rather fast) to the speed libcairo can draw gradients and > anti-aliased curved lines (comparatively rather slow). > > Though it does seem sluggish, even so. Perhaps there are some simple > changes that could be made to togglebutton, Ambiance or cairo to speed > it up. I don't have time to investigate, sadly :-( > > John > _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
