Don't do file-read progress bar updates with a timeout; instead, update

the progress bar up to 100 times, as we get another percent closer to
completion.  That reduces the number of times we run the GTK+ main loop;
that main loop may do a "select()" or "poll()" or FIONREAD "ioctl" to
check for input from the X server, adding to the CPU overhead of reading
a file.

The packet filtering progress bar is already updated in a similar
fashion; make it also do up to 100 updates.

svn path=/trunk/; revision=597

1 files changed, 4 insertions, 1 deletions

diff --git a/file.h b/file.h
index 7b9da7f7ae..5be11cfe5e 100644
--- a/file.h
+++ b/file.h
@@ -1,7 +1,7 @@
 /* file.h
  * Definitions for file structures and routines
  *
- * $Id: file.h,v 1.41 1999/08/24 16:27:23 gram Exp $
+ * $Id: file.h,v 1.42 1999/08/28 01:51:57 guy Exp $
  *
  * Ethereal - Network traffic analyzer
  * By Gerald Combs <gerald@zing.org>
@@ -63,6 +63,9 @@ typedef struct _capture_file {
   guint32      esec;      /* Elapsed seconds */
   guint32      eusec;     /* Elapsed microseconds */
   guint32      snap;      /* Captured packet length */
+  gboolean     update_progbar; /* TRUE if we should update the progress bar */
+  long         progbar_quantum; /* Number of bytes read per progress bar update */
+  long         progbar_nextstep; /* Next point at which to update progress bar */
   gchar       *iface;     /* Interface */
   gchar       *save_file; /* File that user saved capture to */
   int          save_file_fd; /* File descriptor for saved file */