Hi,
ext Adalbert Dawid wrote:
> 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...
If you're using compiz, i.e. composited windows with shadows etc,
Windows (XP) is not really comparable, you should be comparing the
speed to (similarly HW accelerated) Windows Vista or to KDE which also
uses a composite manager (or window manager with builtin composite
manager). AFAIK composited windows have a double buffer (i.e. large
OpenGL texture) at the X server side which needs to be re-created each
time the window size changes (in addition to buffering that is done to
get flicker-free drawing at the X client side).
- Eero
_______________________________________________
Performance-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/performance-list
