Den 10 jan 2016 14:50 skrev <bugzilla-daemon@xxxxxxxxxxxxx>:
>
> 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 <wireshark-bugs@xxxxxxxxxxxxx>
> Archives: https://www.wireshark.org/lists/wireshark-bugs
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-bugs
> mailto:wireshark-bugs-request@xxxxxxxxxxxxx?subject=unsubscribe