http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1752
Summary: Follow TCP dialog in ASCII and raw modes is too slow
Product: Wireshark
Version: 0.99.6
Platform: PC
OS/Version: Linux
Status: NEW
Severity: Normal
Priority: Low
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: jkohen@xxxxxxxxxxxxxxxxxxxxx
Build Information:
Version 0.99.6pre1
Copyright 1998-2007 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled with GTK+ 2.10.13, with GLib 2.12.12, with libpcap 0.9.7, with libz
1.2.3, with libpcre 6.7, without Net-SNMP, with ADNS, without Lua, with GnuTLS
1.6.3, with Gcrypt 1.2.4, with MIT Kerberos, with PortAudio <= V18, without
AirPcap.
Running on Linux 2.6.22.2, with libpcap version 0.9.7.
Built using gcc 4.1.3 20070601 (prerelease) (Debian 4.1.2-12).
Wireshark is Open Source Software released under the GNU General Public
License.
Check the man page and http://www.wireshark.org for more information.
--
Scrolling in the follow TCP dialog in ASCII and raw modes is too slow when the
lines are too long, especially when using the mouse wheel. This is particularly
common for XML and binary data, among others. 20 kB of data produces a
noticeable slow down. A couple hundred kilo bytes of data kill performance.
I traced the problem back to the word wrap flag in the GtkTextView. It should
be possible to pre-wrap the lines to fit the width of the dialog. Given that
this dialog is usually monospaced (non-fixed width word wrapping does not even
finish loading here) and only characters in the ASCII range are displayed in
all supported modes, this should represent no problem.
The resizeable flag of the dialog could be removed or, alternatively, the
temporary file from which the stream is loaded could be kept around for as log
as the dialog is open, so that the data can be re-wrapped on resize. Yet
another alternative would be to tag the soft-breaks so that they can be
repositioned on re-wrap without needing to keep the temporary file around. This
would require additional memory to store each soft-break's tag, though.
I don't think that people would be resizing the dialog all the time, and the
performance benefit obtained by pre-wrapping is enormous. Note that wrapping
the data should be as simple as outputting a newline character after a run of N
characters not containing a newline character, where N doesn't change until the
window is resized (given the Monospace font assumption noted above).
Furthermore, this would allow to add a linewrap marker ala Emacs.
I don't have much experience with GTK+, but I created a working test case that
I used to trace the problem and I think I could implement my suggestions on the
test case and on Wireshark as well, if they would be considered for inclusion.
--
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.