On Mon, Dec 01, 2003 at 05:57:48PM +0100, Biot Olivier wrote:
> Hi List,
>
> Today the GUI code always operates on *all* packets, while in many
> situations it would suffice to operate on the displayed packets only. For
> this reason, I have some ideas I want to share:
>
> 1. Colorize only the *visible* packets (even with a defined dfilter). This
> should be fairly simple to achieve, as we can compute the number of
> displayable rows at any time.
Simple to achieve *if* there's a way to be told when a packet is
displayed and set the color of that row at that time. It might be
possible to do that with the "scroll-vertical" signal with a GtkClist.
Another way to do that would be to have a widget where the row's text
and color is determined when a row is drawn in the screen, by a
callback.
The problem with any scheme that does stuff when a row is made visible
is that it'd require that the packet be dissected when its row is drawn
- which would require that dissection to happen reasonably quickly,
which would, in turn, require that the data for the packet be read
reasonably quickly, meaning random access to the capture file be
reasonably fast.
If the file isn't gzipped, it is probably reasonably fast; if it *is*
gzipped, however, it's not fast, especially if you have to move
backwards in the capture.
Fast random access to a gzipped file is probably implementable if you
have saved versions of the uncompressor state at various points in the
capture; going to an arbitrary point in the file would then involve
going to one of the points where the state was saved, and moving
forwards (if uncompression of the chunks between those points was done
into an in-memory buffer, moving within the chunk would be reasonably
fast).
