Re: Unaccounted time during containers' lifecycle

[Tapani Pälli <tapani palli nokia com>]

Hello,

ext Matt Hoosier wrote:
> Hi,
>
> I have some use-cases where I'd like to use a window containing grids
> of composite widgets. The amount of time which elapsed between the
> moment the widgets are all constructed, and when the window containing
> them is first exposed, seems to be disproportionately long compared to
> the raw amount of painting work to be done by those widgets
> themselves.
>
> That probably sounds a little vague; let me offer a concrete example
> [not attached]. If I want to display a 9x4 set of buttons, I can
> either (a) use individual GtkButtons inserted into a GtkTable, or (b)
> derive a custom widget type which manually overrides its expose
> handler to make gtk_paint_box() calls to simulate the appearance of
> those 36 buttons.
>

This is how the virtual keyboard of 770 was optimized. Initial
implementation was a container having gtkbuttons inside and it was way
too slow. Then we decided to go for a custom widget that has one button
and calls gtk_paint_box() using it's style + draws textlabels using Xft
and it was much faster, I don't remember the exact figures but many
times faster anyway. The code for detecting mouse hit to each button is
quite trivial so I'd suggest to use this method if you're building a big
table of buttons.


> The first approach using nested widgets takes about 1100 seconds from
> beginning of construction to the end of the first expose. I did a
> second implementation that just draws everything as one huge widget
> (the second approach) and it takes about 300 ms.
>
> My first thought was that size negotiation for all the individual
> widgets could be taking most of the additional time. So I implemented
> a custom version of GtkTable which never consults its children when
> determining its requisition; it just requests the amount of space
> which I already know will be needed by the whole grid.
>
> This made almost no difference. I suppose that's because the
> GtkLabel's contained within the individual GtkButton's must eventually
> calculate the on-screen size of their encapsulated PangoLayout anyway,
> so one doesn't really save much by avoiding the
> gtk_widget_size_request() calls on them.
>
> So, I wrote a little test program which just builds a GtkWindow
> containing a 5x5 GtkTable in which each element is a composite widget
> looking like this:
>
>  GtkVBox
>    GtkHBox
>      GtkButton
>      GtkAlignment
>    GtkHBox
>      GtkLabel
>      GtkCheckButton
>
> (Why the more complex structure instead of simple buttons? It's a
> little more close the actual application that motivated my inquiry to
> begin with.)
>
> I attached some callbacks with timer outputs to each of the following
> signals on the top-level window:
>
> * expose
> * map
> * realize
> * size-request
> * size-allocate
>
> The program just endlessly builds instances of these windows, waits
> until they're exposed, and then destroys them. Here's one trace which
> shows a typical set of results (there's little variance from one cycle
> to the next, so I'm not including a huge dataset).
>
> [Cycle 7]: construction finished at 0.1030 sec
> [Cycle 7]: requisition computed at 0.2150 sec
> [Cycle 7]: size allocated at 0.2287 sec
> [Cycle 7]: realized at 0.2315 sec
> [Cycle 7]: mapped at 0.2605 sec
> [Cycle 7]: requisition computed at 0.4137 sec
> [Cycle 7]: size allocated at 0.4409 sec
> [Cycle 7]: exposed at 0.4436 sec
>
> ( If the timings look a little slow, that's because I'm working on an
> ARM system. )
>
> So, a couple of questions seem to follow from that:
>
> * Why is the size negotiation done twice before that window appears
> on-screen? I'm attaching the program used to generate the timings
> below, and I don't see any setter calls made on a widget after the
> window is shown, that would cause it to do a queue_resize().
>
> * Am I wrong in my earlier speculation that the size-request phase is
> not really very expensive? I wouldn't mind at all being contradicted
> about that.
>
Maybe not very expensive, but overload anyway compared to the custom
widget approach.

> * Does something else other than size requisitions happen between the
> time that gtk_window_show() is called on a toplevel container, and the
> time that its "size-request" signal fires?
>
> In general, I'm wondering why containers seem so much slower than
> writing a messy monster widget that manually draws everything. The
> actual time expended painting the whole window looks like about 3
> milliseconds, which is insignificant compared to the overall time
> required for setup. I've run sysprof on an x86 build of the program
> used to generate the timings, and no particular function stands out as
> a hotspot.

// Tapani