| From: Guy Harris
|
| 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.
Umm... do we really need a GtkCList? The most simple approach would be to
redissect the packets we have to display (get 1st matching packet; dissect
and display while not all visible packets are shown).
| 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.
If we know that we only have to display a limited number of rows (today's
computer monitors would not display more than 100 rows I think), we may
decide it is acceptable to redissect the visible rows for the colorization.
We can link the color to the "visible row index", hence removing the per-row
callback requirement.
| 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.
Ah. That's the major problem I think. However...
| 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).
Maybe we can save the decoding dictionary in a temporary file at the time we
read the file? I was thinking whether this could be beneficial for
uncompressed file reading too...
Regards,
Olivier
