A-ah! It's the coloring rules. I forgot about those!
Thanks Jaap!
Fabrizio

On Jan 24, 2008, at 2:37 PM, Jaap Keuter wrote:

> Hi Fabrizio,
>
> The proto_tree pointer will be != NULL when the entire tree is needed.
> That is not only the case when the packet is selected and the details
> are displayed, but also when filters are in effect. These filter
> expressions can only be evaluated when the dissection details are  
> known.
> Even if you don't have a display filter set the coloring rules are  
> based
> on display filters and have the same effect.
>
> So, clear out the display filters and disable packet coloring. Then  
> you
> will get proto_tree == NULL and hopefully faster load times.
>
> Thanx,
> Jaap
>
>
> Fabrizio Bertocci wrote:
>> All,
>> I am working on a newer version of the RTPS packet dissector (real-
>> time publisher/subscriber).
>> I have noticed that my packet dissector gets called every time with
>> the proto_tree parameter not NULL, including when the packets are
>> loaded in memory.
>> Unfortunately there are some complex packets that require some heavy
>> computation that should not be necessary unless the packet is
>> selected. As result of this, loading a file (with those packets)
>> takes quite a long time...
>>
>> The documentation said that wireshark calls the packet dissector with
>> proto_tree != NULL only when the entire tree is needed.
>> Any idea why? Is it something that has changed over the time? Is it
>> something I'm doing wrong?
>>
>> I'm registering the protocol on top of UDP with a simple call to:
>> heur_dissector_add("udp", dissect_rtps, proto_rtps);
>>
>> Thanks for any help provided!
>> Fabrizio
>>
>
>
> _______________________________________________
> Wireshark-dev mailing list
> [email protected]
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>

_______________________________________________
Wireshark-dev mailing list
[email protected]
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Reply via email to