[Twisted-Python] GUI responsiveness

Mike Pelletier mike at mkp.ca
Wed Sep 14 10:01:18 MDT 2005


Oh good, a tangential conversation that I'm not really qualified to comment on 
with no real significance to the subject of the list.  My favourite!  I must 
add my two cents.  ;-)

On Wed September 14 2005 08:05, glyph at divmod.com wrote:
> Not at all.  A user clicks on a button; if they don't see an update for
> 100ms, that is barely enough time for them to flick their mouse over to
> another button.

100ms seems like an awfully long time for a GUI to go without even providing 
feedback to the user (ie, depressing a button, colouring a link, highlighting 
a control, etc).  Consider especially operations like drag-and-drop and using 
spinners, which are very interactive and require fine motor movement.  Also 
consider interacting with dense and complex controls with lots of small 
clicking areas, as in a DTP app or 3d modeller.  Timely feedback is very 
important to a comfortable experience.  After 8 hours of using something with 
mushy, >100ms feedback, I would be cursing the invention of the mouse.

I drank deeply of the Be koolaid.  I think the goal should be for an interface 
should remain responsive at interactive levels in all conditions, even when 
the rest of the app is busy and unresponsive.  Feedback to user actions 
should seem instantaneous (much closer to 10ms than 100ms), even -- 
especially! -- if the user's actions cannot be resolved for some seconds.

> If the UI isn't redrawing for 100ms, it is hard for the user to even
> notice, unless it is a continuous 100ms between redraws, in which case this
> GUI application is really doing quite a lot of work!

10fps is a pretty feeble goal in a lot of application spaces.

Of course, I recognize that Twisted is a framework for network apps, not UIs.  
But that's almost an argument *for* separating the UI and network event 
loops.

> A news aggregator I use, straw, does blocking DNS lookups and can hang
> completely for upwards of a minute while it's doing an update.  While this
> is not exactly ideal behavior, it's tolerable.  Even Firefox locks up for a 
> few seconds when rendering a complex page.

"These other apps suck, so ours can suck too"?

> You are somewhat overstating 
> the case - I sure wish that everything were faster, but 100ms latency on
> certain operations is not going to make anyone stop using an application
> :).

I use Konq rather than Firefox because, on my turn-of-the-century equipment, 
Firefox is too unresponsive.  Of course, I sacrifice a lot of the "web 
experience" but a) good riddance and b) unresponsive apps aggravate me, 
perhaps more than the average user.

> A few things:

Though I disagree with your assumptions, I can't argue with your points.  I'm 
tempted to think this is a failing of Python (the heresy!).  It seems like 
because of issues like the GIL, one needs to put the interface and the 
machinery in completely separate processes to reach Be-like ideals.

Mike.




More information about the Twisted-Python mailing list