Ethereal-dev: [ethereal-dev] We're building the protocol trees even if there aren't color filt

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

Date Index Thread Index Other Months All Mailing Lists
Date Prev Date Next Thread Prev Thread Next
From: Guy Harris <gharris@xxxxxxxxxxxx>
Date: Fri, 27 Aug 1999 20:16:24 -0700
...which adds a fair bit to the CPU time when reading a file.

The problem appears to be that the "CFILTERS_CONTAINS_FILTER()" macro in
"colors.h" is testing whether we have a GtkCList of color filters, not
whether we have a non-zero number of color filters - we always have that
GtkCList, even if we have no color filters, as we use it in the dialog
box used to edit color filters.

Unless that's intentional (in which case we need some *other* way for
"add_packet_to_packet_list()" to figure out whether there are any color
filters, so it doesn't always think there are), I think this patch
should fix things (it definitely sped up file reading on one large file,
when I renamed my "~/.ethereal/colorfilters" file).

Index: colors.h
===================================================================
RCS file: /usr/local/cvsroot/ethereal/colors.h,v
retrieving revision 1.1
diff -c -r1.1 colors.h
*** colors.h	1999/08/24 16:27:21	1.1
--- colors.h	1999/08/28 03:02:19
***************
*** 39,45 ****
  #define MAX_COLOR_FILTER_STRING_LEN 256
  
  #define CFILTERS_CONTAINS_FILTER(cf) \
! 	((cf)->colors->color_filters != NULL)
  
  extern GdkColor 	proto_colors[MAXCOLORS];
  extern GdkColormap*	sys_cmap;
--- 39,45 ----
  #define MAX_COLOR_FILTER_STRING_LEN 256
  
  #define CFILTERS_CONTAINS_FILTER(cf) \
! 	((cf)->colors->num_of_filters != 0)
  
  extern GdkColor 	proto_colors[MAXCOLORS];
  extern GdkColormap*	sys_cmap;