Wireshark-dev: Re: [Wireshark-dev] [Wireshark-bugs] [Bug 11980] The filtering speed is impacted
From: Anders Broman <[email protected]>
Date: Sun, 10 Jan 2016 16:43:01 +0100

Den 10 jan 2016 14:50 skrev <[email protected]>:
> Comment # 6 on bug 11980 from Peter Wu
> You are right, coloring always need to happen (whenever color rules exist).
> (What about tshark? Colors are normally not shown, but if the two
> frame.coloring_rule fields are shown in the frame tree/columns, should the
> color calculation also be done?)

Do we know if it's a tshark run? If so skip the fields?

> For a start, to calculate on the first pass (pinfo->fd->flags.visited == 0).
> This did not work because the fields from the color filter are not primed yet.
> Possible fix: always invoke dfilter_prime_proto_tree before
> epan_dissect_run{,_with_taps} (similar to epan_dissect_prime_dfilter).
> The next problem is that the applicable color may change during subsequent
> redissections.

Do the opposite, only run on second pass? Is it only needed for visible frames?

> Possible fix: introduce a new fd->flags.need_colorize which must be set before
> the initial dissection in GUI and again after changing color rules. Clear flag
> after after recalculation.
> Alternative fix: introduce a new global flag (eww), that behaves similar to the
> previous fix, but outside frame_data.
> Those fixes will then bring the coloring rules at the same level as display
> filter rules, allowing filtering as well.
> ________________________________
> You are receiving this mail because:
> You are watching all bug changes.
> ___________________________________________________________________________
> Sent via:    Wireshark-bugs mailing list <[email protected]>
> Archives:    https://www.wireshark.org/lists/wireshark-bugs
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-bugs
>              mailto:[email protected]?subject=unsubscribe