Wireshark · Ethereal-dev: Re: [Ethereal-dev] Protocol tree for filters

[Ed Warnicke <hagbard@xxxxxxxxxxxxxxxxxxx>]

On Wed, 10 Jan 2001, Guy Harris wrote:

> > 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.

This seems to be an accurate description of what I'm seeing.  

> 
> *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....)

Yep.  I'm running Xfree86 4.0.2 from the unstable branch of Debian 
( I vaguely suspect that it is being renamed and Woody is now the testing 
branch).  

> 
> (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.)

Where I can really see the difference is grabbing the scroller and pulling 
it down to scroll rapidly through the list of protocols in the 
"Add Expression" dialog.

I am also now noticing an error when I bring up the "Help" menu item 
and click on the "Display Filters" tab, the error reads 

IMLIB ERROR: SHM can't get SHM Identifier for Shared XImage
             Falling back on XImages

this error is repeated five times.  The various elements of the 
"Display Filter" tab are slowly updated one by on (tab title, filter 
list, right scroll bar, bottom scroll bar, etc).  As you may imagine 
since it happens slowly enough for me to notice the distinct parts, this 
is glacial.  

This is a recent behavior, I can't say when it started happening.  
I suspect this is a Debian bug, since the stable ethereal-0.8.14 that 
I keep around on my system is also experiencing this problem and 
it definitely wasn't before.  

I'd say chalk it up for right now as one of the pains of living on
unstable.  I'll try to take it up with the Debian folks (as soon 
as I have time to isolate it more).  

Ed