Wireshark-bugs: [Wireshark-bugs] [Bug 1752] New: Follow TCP dialog in ASCII and raw modes is too
Date: Sun, 19 Aug 2007 19:57:56 +0000 (GMT)
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.
- Prev by Date: [Wireshark-bugs] [Bug 1751] Direction info missing for Bluetooth H4 captures in pcap-format
- Next by Date: [Wireshark-bugs] [Bug 1753] New: mpeg: Further improvements to the MPEG decoder
- Previous by thread: [Wireshark-bugs] [Bug 1751] Direction info missing for Bluetooth H4 captures in pcap-format
- Next by thread: [Wireshark-bugs] [Bug 1753] New: mpeg: Further improvements to the MPEG decoder
- Index(es):
- Get Wireshark
- Download
- Code of Conduct