Dialer UI Design
Nishit Dave
stargazer.dave at gmail.com
Tue Sep 30 15:34:18 CEST 2008
On Tue, Sep 30, 2008 at 6:55 PM, Alex Osborne <ato at meshy.org> wrote:
> You mean start Mofi, then switch to a different app and back to the
> still running Mofi? The window renders virtually instantly for me,
> there's a little flash of it redrawing but you really have to watch
> for it and it's not noticeably worse than any other app. I'm
> switching between xterm and Mofi on Debian on the FreeRunner. The
> fact I can't see it could be due to Debian using a different GTK
> theme, I notice the font (and hence all the widets) are much smaller
> on Debian than on OM 2007/8, so it might render faster.
>
It might be because I use a Qtopia-based installation (2008.8-update) then,
and GTK might run better on Debian 'natively', I guess.
>
> The fact that Python is used for the application logic should have
> zero effect on the redraw speed. This is because the code that does
> the drawing (GTK), is actually written in C. The Python code tells
> GTK once when the window is created, "hey I want five buttons and a
> textbox with this text, in this arrangement, you figure out the
> rest", it's then GTK's responsibility to redraw them and tell python
> when a button gets clicked or a menu item is selected. In a normal
> application that's just using standard widgets and not doing any
> custom drawing, redraws (like switching between applications)
> shouldn't execute any Python code at all.
>
This is very informative, thanks. I still have the feeling that GUI
performance is poor when the executable is written in python. Maybe its
just me.
> But for typical GUI programs processor speed is usually largely
> irrelevant as long as the underlying toolkit is not completely
> broken. If a GUI is not responding it's a problem with how the
> program is structured, it should be doing something asynchronously
> instead of blocking the event loop.
>
> I just hope everybody follows best practices. At the end of the day, all I
need is something that is responsive.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20080930/4b58e66a/attachment.htm
More information about the community
mailing list