https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4037
Jim Young <jyoung@xxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jyoung@xxxxxxx
--- Comment #6 from Jim Young <jyoung@xxxxxxx> 2010-01-26 18:41:31 PST ---
One easy way make the scrolling issue apparent is to use coloring rules.
Disable all the current coloring rules and then create a new one (preferably
red!) with the filter "frame.number <= 10". It will then be easy to see that
on each new packet update the packet list will temporarily show the first (now
red) frames from the top of the packet list and then newest frames from the
bottom of the packet list.
With the "Test patch" applied the packet list window no longer exhibits the
"scolling up" issue; instead on each update the last N most recently arrived
frames. I did a test capturing from a PC that was sending at about 8000
packets a second and the screen updates kept up nicely.
But the patch is not quite ready for prime time. After stopping the capture if
I apply a display filter that results in zero matching packets (e.g. "!frame"),
Wireshark crashes (on a Windows build). But the test patch is like a nice
start to resolving the scolling issue.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.