Comment # 9
on bug 12228
from Guy Harris
(In reply to Guy Harris from comment #7)
> (In reply to Pascal Quantin from comment #6)
> > Given that it works fine with the GTK UI, I'm wondering if we are not
> > hitting a performance issue with QTreeWidget class. Is the limitation really
> > coming from the number of data sources, or the number of QTreeWidgetItems ?
>
> 1447 fields, which isn't all that huge.
I have a capture with what I call the Packet From Hell - it's a NIS YPALL
response that is about 437,000 bytes long (no, that is not a typo), reassembled
from 49 ONC RPC fragments, with each fragment having about 7 TCP segments, for
a total of about 343 TCP segments. It has 46405 fields.
It's still expanding, after starting an "expand all" from the View menu in the
GUI; it's been running for about 15 minutes.
I've attached the result of running OS X's sample program (from within Activity
Monitor) on it whilst running. It's doing a lot of layout, drawing, and sizing
of text. Perhaps we need to have a lazy text widget that doesn't bother trying
to process the text of any rows that aren't actually on screen. (The Packet
>From Hell is a good test of a lazy hex dump pane widget - in a GTK+ version
that just used a regular text widget for the hex dump pane, it took a
*significant* amount of time, as in "quite noticeable to a user", just to
construct that pane.)
You are receiving this mail because:
- You are watching all bug changes.
