Gerald Combs skrev 2011-04-25 19:08:
On 4/23/11 3:12 PM, Guy Harris wrote:
On Apr 23, 2011, at 11:29 AM, Jakub Zawadzki wrote:
About actual bug:
In old packet list _freeze stops GtkClist from redraw while adding packets to list.
In new packet list _freeze sets empty (NULL) model, and _thaw restores model with packets.
Are there any places where freezing and thawing the list is useful any more?
The freezing/thawing code dates back to at least SVN r2 (no, that is *NOT* a typo!) of file.c:
------------------------------------------------------------------------
r2 | gerald | 1998-09-15 19:39:15 -0700 (Tue, 15 Sep 1998) | 2 lines
Initial revision
------------------------------------------------------------------------
Gerald, do you remember (from almost 13 years ago!) why you froze the GtkCList when reading the capture in and thawed it when done? Is this something that applied to the old GTKCList but that doesn't apply to GTK2's tree view?
I'm pretty sure it was for performance reasons. Each change to the
packet list triggered a lot of synchronous updates which you could defer
by freezing and thawing the list.
Hi,
After looking at the code and running the debugger I'd be inclined to remove
#ifdef HAVE_LIBPCAP
if (progbar_quantum > 500000 || displayed_once == 0) {
if ((auto_scroll_live || displayed_once == 0 ||
cf->displayed_count < 1000) && cf->plist_end != NULL) {
displayed_once = 1;
new_packet_list_thaw();
if (auto_scroll_live)
new_packet_list_moveto_end();
new_packet_list_freeze();
}
}
#endif /* HAVE_LIBPCAP */
I think that code was designed to show packets in the list during
loading of a file but as Jakub indicates the loading is considerably
faster without doing it. Auto scroll in live captures seems unaffected
by the code change, the list
will be frozen during the entire loading of the file an thawed at the end.
Best regards
Anders
