Re: Performance hit?

[Owen Taylor <owt1 cornell edu>]

johannes@nada.kth.se (Johannes Keukelaar) writes:


> Hey All,
> 
> I am working on an application that, simplified, looks a bit like this:
> 
> +--------------------+------------+
> |                    |            |
> | custom drawing     | scrolled   |
> |  widget            | window     |
> |                    |            |
> +--------------------+------------+
> |      X: foo  Y: bar             |
> +---------------------------------+
> 
> The custom drawing widget and the scrolled window are together in a hpaned 
> widget. The custom drawing widget has an even callback that updates the X and Y 
> labels to show the coordinates of the mouse. Now, as I add widgets to the 
> scrolled window (on the order of, say, 500 nested widgets), I experience a 
> significant performance hit (on a SUN Ultra 1) in terms of update speed of the 
> X and Y labels.
> 
> Why is this? You'd think that since the path through the widget hierarchy to my 
> custom drawing widget does not depend on the subwindows of the scrolled window, 
> there would not be a performance hit in this respect. Has anyone else seen 
> similar behaviour? Even better, does anyone have an explanation, or even a fix?

The problem is that when you change the labels, the width of the
dialog could potentially change. GTK figures out what actually changed
by size-requesting the entire dialog.

Since the Viewport isn't currently smart enough to know that it
doesn't have to size-request its children in that circumstance, you
see the performance hit.

I don't, off-hand, see a way of fixing this other than improving
GTK's resizing code.

(You'd think that it would work to do:

  gtk_container_block_resize (box_holding_labels)
or
  gtk_container_disable_resize (box_holding_labels)

but with current queued resizes, neither will do the job :-()

Regards,
                                        Owen