On 7/5/06, Padraig O'Briain <[EMAIL PROTECTED]> wrote: > Our QA team has reported roughly a 10% degradation in gtkperf > performance when comparing GNOME 2.6 and GNOME 2.14. > > GNOME 2.6 is using gtk 2.4.9 and GNOME 2.14 is using gtk 2.8.17. > > gtkperf is CPU bound and most of the CPU is used by the X server.I used > a special version of Xorg with dtrace probes, see > http://people/freedesktop.org/~alanc/dtrace, to identify that most of > the CPU is being used by the RENDER extension and within that by > RenderComposite > requests. > > The worst degradation is being seen in the first three tests in gtkperf, > i.e. GtkEntry, GtkComboBox and GtkComboBoxEntry. > > Most of the RenderComposite requests are inexpensive but there are a > handful of expensive ones. In one example I am looking at 18 calls out > of 444 each take about the same amount of time and account for roughly > 2/3 of the total cost. > > All the expensive XRenderComposite calls seem to be associated with > calls to gtk_paint_box_gap which is called from gtk_notebook_paint which > is called from gtk_notebook_expose. > > I have looked at all the calls to gtk_paint_box_gap during one iteration > of GtkEntry, GtkComboBox and GtkComboBoxEntry tests in gtkperf using gtk > 2.4 and gtk 2.8 to see if there is any correlation between the arguments > passed to gtk_paint_box_gap and the expensive calls. It looks like the > expensive calls are the ones with the largest area. See data below. > > I am looking for help at this stage. > > Should we expect the calls to gtk_paint_box_gap to be so expensive?
What part of it is expensive ? I am a bit puzzled, since it seems to be only a) clear the background and b) draw a bunch of lines. a) should now use core X protocol, not render/cairo (see setup_backing_rect_method) b) should also just use core X protocol _______________________________________________ Performance-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/performance-list
