Dialer UI Design

[Alex Osborne]

On 30/09/2008, at 9:41 PM, Nishit Dave wrote:

> How about experience? I don't know about programming or system  
> specifics, but as a user,

Please don't take this the wrong way.  There's a common misconception  
amongst non-programmers and even some less experienced programmers  
than anything except compiled code is going to feel slow.  This is  
what Mickey means by "prejudice", you're judging that a poor user  
experience is Python's fault without really understanding how things  
work.  I'll try to explain below.

> You can test that on the FR - just try Mofi, switch to say the home  
> screen, and switch back.  You will be able to see how long it takes  
> before text appears.

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.

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.

When you click scan the interfaces freezes, but that's because it's  
waiting for the hardware to do the wifi scan.  This is poor practice,  
it should really do the scan asynchronously so the interface doesn't  
freeze and display a spinner, or at least say "Please wait,  
scanning...".  At least the freeze is not very long.  But again, that  
has nothing to do with the programming language used, it's just as  
easy to make the same mistake with C.

> Just from an efficiency point of view, don't you think a compiled  
> program may run better than an interpreted one on a system with  
> limited hardware capabilities.

For doing math intensive stuff like drawing, compression, encryption,  
etc -- sure definitely -- you're trying to do hundreds of millions of  
operations per second.  For app logic, when this button is pressed,  
turn on the wifi, configure it with these settings and such there's  
really no difference between a few thousand CPU cycles of tightly  
optimized C code and a tens to hundreds of thousands of cycles of  
Python per button click, they're both imperceptible and are both not  
a bottleneck.  Can you tell the difference between 1 microsecond and  
1 millisecond?  I certainly can't.

I guess one might be able to form an argument that Python has a lower  
barrier of entry for programmers than C so you would be more likely  
in general to get programs written by less experienced people, but I  
personally might actually call that a point in favour of Python. ;-)   
It also by no means implies that Python programs are *only* written  
by inexperienced people.

I hope that makes things a bit clearer.  Analysing software  
performance is actually a very complex process and more often than  
not it's not just raw computation speed that wins the day.  Often  
your intuitions like that compiled code should be better than  
interpreted byte-code often do not hold, as good code can often be  
exponentially better than bad code, while compiling might get you at  
the very most only a 5 to 10 times speed boost.  Also, how caching  
and memory is used plays a very large role in the performance of  
programs running on modern hardware.

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.

Cheers,

Alex