|
Arg, forgot the list. -------- Mensagem original --------
Adalbert Dawid escreveu: > For example, if you create a GTK window and populate it with a single > GtkButton (which will resize along when one resizes the window). Now > select the "classic" GTK theme, so that the button is just a flat, grey > area. No gradients, no further calculations should be necessary when the > button gets bigger. Now resize the window and you will notice that the > repaints get *much* slower when the window (and the embedded button) gets > large. But why is that? The button is only a flat grey area, so one would > expect that it can be drawn equally fast, independently of it's size. > > I hope, that makes my thoughts clearer now. > As much as one could blame X for that (not having a fast enough path for graphic data or a proper way to draw flicker-free widgets without holding a double buffer for each window), one can see the same effect on GTK on windows too. Just take gaim and try to resize a chat window. Is the well know gray resize effect that happens to swing apps as well. Now, why GTK need to do that? Is the synchronized resize that slow that needs to use an assync painting to now slow it down or something? I'm no GTK expert, but when one sees what ETK (a GTK-like port to e17) perfoms a lot a better, start to wonder what is wrong... My first guess would lead me to take a look at the theme engine and see what it is doing down there, and if it possible to make it work better. Solerman |