On Wed, Nov 19, 2003 at 09:26:47PM +1100, Ronnie Sahlberg wrote:But it doesn't solve the main issue: filters are slow.
You do not use any color filters.
Correct. Not everybody does, so getting rid of the filter would still help.
However, it might be possible, with a summary list widget with a
callback, to have the color set when a row is displayed - dissect the
packet when the row is displayed and, if there's a color filter,
construct a protocol tree, run the color filter, and color it then. (Think of it as "lazy coloring".)
Can we tell from a filter if we need to fully decode a protocol?
What about a display attribute in the tree structure, with it we might 'if enclosed' a lot of expensive sprintf calls.
BTW there's a bug in tcp desegmentation when packets are lost, retransmited:
%
63.83 11.01 11.01 13448 0.00 0.00 fragment_add_work
1.80 11.32 0.31 tcp_segment_equal
1.74 11.62 0.30 23063 0.00 0.00 dissect_tcp
it's 20MB AFP capture.Didier
