[maemo-users] [maemo-users] Bad unjustified reputation ?

From: Lassi Syrjälä lassis at cc.jyu.fi
Date: Mon Jan 23 23:52:18 EET 2006
Clemens Eisserer kirjoitti 23.1.2006 kello 19.48:


> 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.. :)


More information about the maemo-users mailing list