> Possibly. The machine is a PII 400, the video card is a G200, but I
> am running it in 1600x1200 at 24 bits/pixel. The reason it seemed strange
> was because the packet window doesn't have the same sort of problem,
> it scrolls just fine, no lag in refresh at all, not nearly the processor
> hit. Hmm... very weird.
If I run a version built on Solaris and have it display to Exceed
running on W2K (same monitor as I have at home), it doesn't seem to have
a problem.
*However*, a version built on HP-UX, displaying to the same X server,
seems to draw a number of things *painfully* slowly; it seems to scroll
OK through the protocol tree window, but scrolls with some lag in the
list-of-filterable-fields window...
...and the packet list window. It also draws slowly in a number of
other places.
*Part* of that *might* be that the protocol tree, in my case, was much
smaller than the list of filterable fields; if I reduce the packets
shown in the packet list pane with a packet filter, it seems to have
less trouble scrolling.
"vmstat" doesn't show any significant amount of paging or CPU activity,
so that doesn't seem to be the source of the problem.
In my case, it could conceivably be either a clogged network or a botch
in either the client or server or both networking implementations; in
your case, I assume the application and the X server are running on the
same machine, and it's probably not a botch in the UNIX-domain socket
implementation.
Perhaps some X client libraries have a problem that GTK+ somehow
triggers? (However, you're probably using some flavor of XFree86's
client libraries, and my home machine is doing the same, and I'm not
sure what a client library would do that would make *that* significant a
difference - I mean, you can *see* the HP-UX version draw the packet
list window twice when it reads in a capture, but if the Solaris version
- or my FreeBSD version at home, or my Debian GNU/Linux version at home,
or my Solaris version at home - is doing that, you sure can't see
it....)
(I wonder if there's some mouse event compression going on in the
systems where the scrolling behavior doesn't suck, and if that
compression isn't happening on systems where it does suck, so that as
you slide the scrollbar down, a lot more redrawing occurs?
For what it's worth, if I click and hold the "scroll down" triangle at
the bottom of the packet list scrollbar, the HP-UX version *did* pause
briefly in the middle of scrolling the first time I did that, but didn't
do so on subsequent attempts.)
