http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1700
------- Comment #2 from luis.ontanon@xxxxxxxxx 2007-07-21 23:22 GMT -------
I think he has identifies the time taken to reassemble a long TCP session with
a problem in the lower pane.
The solution for him is not to do the reassembly of the entire tcp-session to
dissect the huge message all at once but instead to reassemble every element
independently. I.e. dissect the container data, create a conversation and use
it to indipendently reassemble only enough data for a single event.
In reply to comment #1)
> If by "lower pane" (there are typically 3 panes, so the middle pane is "lower"
> than the topmost pane) you mean the lowest pane, i.e. the hex display pane,
> yes, Wireshark is attempting to render the lower pane in its entirety, because
> that's the way the GTK+ text widget works.
>
> The right way to fix this would be a widget that is backed by, for example, an
> array of bytes, rather than a pile of text, so that you could just create the
> widget and point it at the data from the relevant tvbuff, and have it fetch
> data and render the text only for lines that it's displaying.
>
> If it's re-running the dissector just because you move from one item in the
> middle pane (protocol tree) to another, that sounds like a bug. There are some
> cases where the dissector appears to be run twice when it probably should only
> be run once; that might be part of the same problem.
>
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.