Clemens Eisserer kirjoitti 23.1.2006 kello 19.48: Hi, > To be honest I did not measure the repaint times, but one example > which I found to be terrible slow is the applications-menu. > If you open it you see how it takes time to come up and to paint > itself (maybe this happens in less than 150ms but its noticeable), and > closing it above the audio-player with a full playlist takes more than > 500ms (it feels like >800ms) to repaint the underlaying audio-player > window. One of the reasons why menus appear slow is that they take focus; when a widget loses or gains focus, its visible area is completely redrawn. I guess this is for simplicity as the toolkit is unaware of the widget's focus indications, and it's easiest to just redraw it. On a resource-constrained device, it'd obviously be nice to be able avoid that (= handle clearing/drawing focus manually), especially if painting is relatively expensive, as in the case of a full playlist, or if there's in fact no visible focus border... > But I saw this behaviour also with other application. > Scrolling tables or lists is slow and you see rendering artifacts, > when making dialogs transparent you can watch main-windows repainting > (>200ms). I think scrolling lists (I assume you mean GtkTreeView) is actually pretty fast. There's artifacts if you scroll quickly but I always thought that was intentional. It's just that updates aren't processed synchronously to make scrolling faster. Synchronous updates could be forced with gdk_window_process_updates (), but that'd just slow down. Yet another reason for the perceived slowness of repaints is the double buffering. One can disable that on a per widget basis, and enjoy faster but more flickery (as the dirty area is not updated at one go but gradually) screen updates. The browser, by the way, seems to work differently from other apps I've seen. It leaves e.g. the remnants of a menu visible (instead of a dull white patch) until it refreshes that part of the widget. I am not sure if it's really any faster but it feels so... it's probably not using (gtk+) double buffering, but it doesn't flicker either. > Please don't think I am nitpicking I just love fast UIs and a fast and > responsive UI is a must-have for apps I create (thats why I don't use > GTK ;) ), and I also played with Palms and Pocket-PCs (even a "slow" > one with 200mhz arm) and both show much better performance-feeling. Well, neither is based on X nor really comparable to the maemo UI, I think. Not that I wouldn't like maemo to be a bit snappier in some cases, though.. :) Regards, Lassi
