From: Clifford Heath <no@...>
Date: 2005-07-13T09:25:51+09:00
Subject: Re: Updating GUIs

Joe Van Dyk wrote:
> What's the best way to do this?  Should I have a Ruby thread that
> calls the update function, sleeps for 0.2 seconds, and then loops? 
> How should the GUI get notified of those changes?

I designed the OpenUI cross-platform GUI tool. We maintained a
draw-list to which any changed GUI object was added. The actual
draw was delayed. The delay was implemented by processing all
queued and incoming events (we controlled the main event loop),
then waiting for a (customisable) delay, usually 0.1-0.2 seconds,
before processing the drawlist. 0.1 seconds is about right, small
enough that a human won't notice the delay but long enough to
ensure that everything that reasonably can happen before redraw
has happened.

Redraw does need to be forced if you want to achieve the impression
of rapid progress (flickering through lists of files being scanned,
etc).

This is an excellent way to minimise redraw activity. It gives
automatic type-ahead - a user can even learn to enter keyboard
data into a popup window and Ok it *without the popup even
appearing*... On a slower computer of course - OpenUI was initially
developed to run on a Windows 3.1 system with only 4M of RAM :-).
The NASDAQ exchange ran on 486's with Windows 3.1 and only 8Mb
of RAM for many years - this was an OpenUI app that was receiving
and displaying sustained UDP broadcast bids and offers at an
average of several per second, maximum rate about ten per second,
with a very low lost-packet rate (there was no recovery from lost
packets). Pretty impressive, even by today's standards.

Clifford Heath.