| 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
