The GUI carefully avoids updating itself for every block
It takes advantage of multicore systems: it uses one process for the GUI, and another for the data transfer.
This is done using Python's excellent multiprocessing
module, rather than threads.
It shows more statistics than is usual for these tools.
It allows display in SI or IEC units or a mix of the two,
and you can change the units mid-transfer.
Here's a pair of pictures of it in action, both run on an Ubuntu 9.10
system with the following specs:
Dual Core Athlon II X2 245, 2913 MHz
Reading from /dev/zero and writing to /dev/null.
Here the CPU is the limiting factor.
Because you can't get a length estimate out of /dev/zero, the
progress bar is pulsing back and forth, not progressing. Also
for this reason the ETA's are "Unknown".
Reading from a tar process that's reading from disk, and
writing to /dev/null.
Here the disk or perhaps the interprocess communication
is the limiting factor.
This is really invoked via gprog-du-tar, so we have
a length estimate, hence the progress bar is growing from the
left. Also, we have ETA data.
Rarely, the GUI won't come up until the transfer is complete. I believe this to be an issue on machines with
almost no free physical memory - EG, it happened on a system with a huge ramfs (ramdisk).
gprog is not suitable for (direct) use with traditional tape drives, because most tape drives want tape blocks to
be of a consistent size. gprog gets a lot of its performance by sacrificing blocksize consistency - this is fine
for disk and network, but typically not for tape.
If you need (GUI) progress with a tape drive, consider putting something like
dd at the end of your pipeline.
The popup signaling a complete transfer is modal. It's no longer modal.