Both things are getting much worse, when the visible part of the
GtkTreeView is pretty large, which is often the case on today's hi-res
screens...
2. Resizing of GTK windows is slow. This effect, too, is getting worse
the bigger the resized window is. It is very interesting to see, that a
really small (say, 200*200 pixels) window can be resized pretty smoothly,
even if it is full of widgets that need to be layouted. Another
observation is, that even an empty GTK window (i.e. one with a plain grey
backgroud and no widgets) repaints really slowly when you resize it on a
screen with high resolution and drag it large.
This indicates that not the layouting of the widgets, but the actual
painting costs most of the CPU cycles and that these costs directly
correlate with the size of the drawing area. I could not observe such a
correlation between the drawing area size and the "redraw-slowness" on
other platforms, like Win or KDE, so I conclude that "there must be
something wrong" in GTK's drawing code. You can clearly see how slow GTK's
repaints are, when you use it together with compiz and try to resize a
window in synchronized mode...