Implementing this is clearly beyond my skill set, so I can do little to make this happen. However, if this will NOT happen by the 0.9.14 release (or even in the more immediate future), I'd like to suggest that the changes I mentioned should be implemented to improve the current situation. At the very least, I think the trivial change to cap auto-resiize width should be added.

Ian

Guy Harris wrote:

Those can probably be fixed, but here are some problems with auto-resize
that might be inherent in auto-resizing:

        It requires Ethereal to generate, for every column to be
        auto-resized (not all columns are auto-resized) whose maximum
        size can't just be computed from the maximum numerical value for
        the column, the text for that column, for every packet.  Right
        now, the GTK+ widget we use requires Ethereal to compute the
        text for every column, but (with some changes, e.g. support for
        fast random access to packets in a gzipped file, which should,
        according to somebody I talked to, be doable if we save copies
        of the compression dictionary values at various points in the
        file) I'd like to use widgets that call back to the Ethereal
        code to get column text, and not generate that text.  This would
        save a significant amount of CPU time and memory.

        It requires Ethereal to compute, for those columns, the pixel
        width of the column values for each row.  At least as I infer
        from this note from a message by Olivier Abad:

- the CList widget in gtk2 is slower, probably because gtk2 uses pango
 to display text (various messages on gtk-app-devel confirm this)

        that's more expensive in GTK2 than in GTK1.  (Unfortunately,
        this *other* note:

- the ListStore/TreeView replacement is painfully slow (also confirmed
 by gtk-app-devel archives).

        indicates that the obvious widget to use, in GTK2, for the
        previous paragraph's problem is slow.  I just hope widgets such
        as Cocoa's NSTableView, QT's QListView, and so on are reasonably
        efficient if you have hundreds of thousands, or more, rows....)

_______________________________________________
Ethereal-dev mailing list
[EMAIL PROTECTED]
http://www.ethereal.com/mailman/listinfo/ethereal-dev






Reply via email to