Re: gtkperf regression and gtknotebook

["Matthias Clasen" <matthias clasen gmail com>]

On 7/5/06, Padraig O'Briain <Padraig Obriain sun com> 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