Re: Unaccounted time during containers' lifecycle

On 4/8/07, Ross Burton <ross burtonini com> wrote:
On Sat, 2007-04-07 at 17:05 -0500, Matt Hoosier wrote:
> 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().

I just had a thought -- the style-set signal might because a
re-negotiate.  I hacked that into the test case:

[Cycle 36]: construction finished at 0.0025 sec
[Cycle 36]: style set at 0.0032 sec
[Cycle 36]: requisition computed at 0.0075 sec
[Cycle 36]: size allocated at 0.0080 sec
[Cycle 36]: realized at 0.0081 sec
[Cycle 36]: mapped at 0.0088 sec
[Cycle 36]: exposed at 0.0726 sec

Hm, style set isn't that slow.  Hm, for some reason I'm not getting the
second requisition/size-allocated pair after the window was mapped.
Where you using a standard theme, or something custom?  (I'm using
Darkilouche, which is based on Clearlooks).

Those tests were run with the stock Gtk 'Default' theme. I also did a
quick check just now to make sure that the stripped down version of
gnome-settings-daemon isn't somehow producing a spurious 'Default' ->
'Default' theme transition. It wasn't; the timings were the same both
with and without that daemon running in the background.

Ross Burton                                 mail: ross burtonini com
                                          jabber: ross burtonini com
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]