kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 02/06/2018 à 14:12, jp charras a écrit :
> Le 02/06/2018 à 11:02, jp charras a écrit :
>> I have made a few tests (not a lot!) and did not see any problem.
>>
> 
> Hi Seth,
> 
> I found an issue due to changes in connectivity algo:
> CONNECTIVITY_DATA::GetPadCount( int aNet ) is significantly slower.
> 
> And creates an issue in copper zones edition, when the net sorting is made by pad count.
> The calculation time is so long it can freeze Pcbnew for large boards.
> 
> This is due to a absolutely non optimized sort function (not optimized due to a lot of changes since
> it was written) and the increased calculation time in CONNECTIVITY_DATA::GetPadCount due to a
> dynamic cast instead of a static cast.
> 
> Could you have a look into this patch that fixes this issue?
> Thanks
> 

Hi Seth,
Please, just have a look into this patch about your change in CONNECTIVITY_DATA::GetPadCount().

I have a better fix for the issue in sort by pad count function used in copper zones settings dialog

Thanks.

>>
>>>
>>> On Sat, Jun 2, 2018 at 12:17 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx
>>> <mailto:stambaughw@xxxxxxxxx>> wrote:
>>>
>>>     On 6/1/2018 3:58 PM, Tomasz Wlostowski wrote:
>>>     > On 01/06/18 20:23, Seth Hillbrand wrote:
>>>     >> I think maybe we are seeing the severity of these bugs differently. 
>>>     >> There are three substantial issues addressed by this patch.  While they
>>>     >> don't affect many users, they do prevent KiCad from being used for
>>>     >> larger, more complex boards that we nominally support.  This is a also
>>>     >> regression from v4.
>>>     > 
>>>     > Hi all,
>>>     > 
>>>     > I vote for merging Seth's patch.
>>>     > 
>>>     > For those concerned about its correctness: the connectivity algo is
>>>     > designed in such way that in case of bugs in collision search (other
>>>     > than in BOARD_ITEM::HitTest()/POLY_GRID_PARTITION which haven't been
>>>     > touched for a year), it may find false unconnected items, but not false
>>>     > connected ones. In the worst case, we'll have false 'unconnected items'
>>>     > warnings in the DRC, but I doubt there will be any. The patch is simple
>>>     > and elegant.
>>>     > 
>>>     > Tom
>>>
>>>     Tom,
>>>
>>>     Have you actually tested the patch?  Voting for it doesn't help me make
>>>     an informed decision.  What I really need is test feedback.  I'm not
>>>     opposed to merging it but I would like as large of a test group as
>>>     possible so I have some confidence that it's not going to cause a bunch
>>>     of issues this close to the stable release.  I plan on testing it
>>>     tomorrow but I am an infinite sample of one.  A few other testers would
>>>     be appreciated before I'm willing to sign off on committing it.
>>>
>>>     Cheers,
>>>
>>>     Wayne
>>>
>>
> 
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


-- 
Jean-Pierre CHARRAS

 pcbnew/connectivity_data.cpp | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/pcbnew/connectivity_data.cpp b/pcbnew/connectivity_data.cpp
index e3ed719..1b37901 100644
--- a/pcbnew/connectivity_data.cpp
+++ b/pcbnew/connectivity_data.cpp
@@ -475,12 +475,15 @@ unsigned int CONNECTIVITY_DATA::GetPadCount( int aNet ) const
 {
     int n = 0;
 
-    for( auto pad : m_connAlgo->ItemList() )
+    for( auto item : m_connAlgo->ItemList() )
     {
-        if( !pad->Valid() )
+        if( !item->Valid() )
             continue;
 
-        auto dpad = dynamic_cast<D_PAD*>( pad->Parent() );
+        auto dpad = static_cast<D_PAD*>( item->Parent() );
+
+        if( dpad->Type() != PCB_PAD_T )
+            continue;
 
         if( dpad && ( aNet < 0 || aNet == dpad->GetNetCode() ) )
         {