Re: [Kicad-developers] Zone filling & display speed improvements

2017-12-05 Thread Henner Zeller
On 5 December 2017 at 06:02, Tomasz Wlostowski
 wrote:
> On 05/12/17 08:55, jp charras wrote:
>> Le 05/12/2017 à 01:41, Tomasz Wlostowski a écrit :
>>> Hi guys,
>>>
>>> Now it should work fine - the filling algorithm was not thread safe and
>>> apparently wxProgressDialog can't be invoked from non-main thread.
>>>
>>> Check out the updated branch.
>>>
>>> Thanks!
>>> Tom
>>>
>>
>> Hi Tom,
>>
>> It works fine for me.
>> And on my 4 cores computer, the speedup is really impressive!
>>
>> Thanks.
>>
>
> Hi guys,
>
> Thanks for testing, I just merged it to the master.

There is still the left-over method RemoveInsulatedCopperIslands()
declaration that is otherwise never defined or used; so this needs to
be done:


--- a/pcbnew/class_zone.h
+++ b/pcbnew/class_zone.h
@@ -151,13 +151,6 @@ public:

int GetClearance( BOARD_CONNECTED_ITEM* aItem = NULL ) const override;

-/**
- * Function RemoveInsulatedCopperIslands
- * Remove insulated copper islands found in m_FilledPolysList.
- * @param aPcb = the board to analyze
- */
-void RemoveInsulatedCopperIslands( BOARD* aPcb );
-
/**
 * Function IsOnCopperLayer
 * @return true if this zone is on a copper layer, false if on a
technical layer


(This will prevent the scripting from compiling as Swig is generating
stub-code from the header but then complains while linking that it
does not exist).

-h

>
> Tom
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Zone filling & display speed improvements

2017-12-05 Thread Simon Richter
Hi,

On 05.12.2017 15:17, Wayne Stambaugh wrote:

> One less pop up window is a good thing.  I like the status bar idea but
> unless you can get it done quickly I would prefer to make this part of
> version 6.  We should be focusing on bug fixing for the stable 5 release.

If the status bar is part of the main window, people will expect it to
be non-modal. For that to happen, we need to change a lot of things
internally — this is desirable, but definitely outside the scope of v5.

   Simon



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Zone filling & display speed improvements

2017-12-05 Thread Wayne Stambaugh
On 12/5/2017 9:06 AM, Tomasz Wlostowski wrote:
> On 05/12/17 13:10, Oliver Walters wrote:
>> Could the filling progress be displayed in the lower statusbar instead
>> of a popup window?
> 
> Great idea, if:
> - someone codes it :-)
> - other progress dialogs are migrated to the new progress bar for
> consistency.
> 
> Tom
> 

One less pop up window is a good thing.  I like the status bar idea but
unless you can get it done quickly I would prefer to make this part of
version 6.  We should be focusing on bug fixing for the stable 5 release.

Wayne

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Zone filling & display speed improvements

2017-12-05 Thread Wayne Stambaugh
On 12/4/2017 10:48 PM, Henner Zeller wrote:
> On 4 December 2017 at 16:41, Tomasz Wlostowski
>  wrote:
>> On 04/12/17 15:43, Henner Zeller wrote:
>>> On 4 December 2017 at 06:31, Tomasz Wlostowski
>>>  wrote:
 On 04/12/17 02:05, Henner Zeller wrote:
> On 2 December 2017 at 10:11, Henner Zeller  wrote:
>> On 1 December 2017 at 08:12, Tomasz Wlostowski
>>  wrote:
>>> On 29/11/17 16:10, jp charras wrote:
 I am using a few board in Kicad demos: interf_u, video, pic_programmer.

 Also, filled areas are no shown in OpenGL, but are shown in Cairo 
 canvas.
>>>
>>> Hi all,
>>>
>>> The branch [1] contains a set of improvements in the zone filling
>>> algorithm. It's several times faster than in the current master branch.
>>>
>>> I'd like to merge it soon and move on to fixing P&S issues pending for
>>> the V5 - I'll greatly appreciate testing and feedback!
>>
>> Hi Tom,
>>
>> I'll compile your branch hopefully later this weekend for testing.
>> If you need another board for testing, I am currently having a board
>> that takes annoying several seconds to fill the zones in head KiCad,
>> which hence might be interesting test case:

 Hi Henner,

 What OS did you build for?
>>>
>>> This was on Debian testing on a x86_64 machine.
>>> g++ 7.2.0, Cairo: 1.15.8, boost 1.62.0
>>>
>>> -h
>>
>> Hi guys,
>>
>> Now it should work fine - the filling algorithm was not thread safe and
>> apparently wxProgressDialog can't be invoked from non-main thread.
>>
>> Check out the updated branch.
> 
> Thanks Tom!
> 
> Nice, the [tom-faster-zones-dec01] branch works well and very fast. I
> have not seen any crashes anymore.
> 
> There is a leftover method mentioned in pcbnew/class_zone.h:
>   void RemoveInsulatedCopperIslands()
> .. which is not used/implemented so should be removed from the header.
> 
> One thing I noticed: since it is sooo fast now, the progress-popup is
> actually quite annoying as it just briefly blinks up and vanishes
> again (at least for the board I was testing it with). Maybe it should
> only show up if the operation is still ongoing after a second and less
> than 50% is done at that time ?
> 
> Another thought: if zone filling can be that fast, maybe we should
> only store zone outlines in the *.kicad_pcb file, not the
> (filled_polygon ...) that are now also stored. It is cheap to just
> recreate them when loading the file.> Backround: This can save a lot of disk 
> space as the filled polygons
> tend to create a lot of points and tend to completely change with tiny
> changes to other elements on the board, such as a moved via. This
> means that version control has to store huge changes every time and it
> is hard to see what actual changes are happening just looking at the
> diff (I like to inspect diffs before checking something in, and this
> makes it hard. Also it makes it hard to git merge kicad-pcbs).
> Downside is, that everyone loading a file has to pay the extra cost to
> create the zones (e.g. gerber generation). Maybe it could be a
> heuristic to not store the filled polygons if recreating it takes less
> than a second or so.

I'm opposed to this idea.  What would happen the next time the zone
filling algorithm is changed?  You would most likely produce different
zone filling which would effectively result in a different board.  This
a huge no-no in production environments where once a board is released,
the expectation is that output plots do not change.  Changes in the
polygon generation could result in boards that worked fine with the
previous filling algorithm but not with the new algorithm.  Refilling
zones on board load is just asking for trouble.

> 
> Cheers,
>   Henner.
> 
>>
>> Thanks!
>> Tom
>>
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Zone filling & display speed improvements

2017-12-05 Thread Tomasz Wlostowski
On 05/12/17 13:10, Oliver Walters wrote:
> Could the filling progress be displayed in the lower statusbar instead
> of a popup window?

Great idea, if:
- someone codes it :-)
- other progress dialogs are migrated to the new progress bar for
consistency.

Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Zone filling & display speed improvements

2017-12-05 Thread Tomasz Wlostowski
On 05/12/17 04:48, Henner Zeller wrote:
> Thanks Tom!
> 
> Nice, the [tom-faster-zones-dec01] branch works well and very fast. I
> have not seen any crashes anymore.
> 
> There is a leftover method mentioned in pcbnew/class_zone.h:
>   void RemoveInsulatedCopperIslands()
> .. which is not used/implemented so should be removed from the header.
> 
> One thing I noticed: since it is sooo fast now, the progress-popup is
> actually quite annoying as it just briefly blinks up and vanishes
> again (at least for the board I was testing it with). Maybe it should
> only show up if the operation is still ongoing after a second and less
> than 50% is done at that time ?
> 
> Another thought: if zone filling can be that fast, maybe we should
> only store zone outlines in the *.kicad_pcb file, not the
> (filled_polygon ...) that are now also stored. It is cheap to just
> recreate them when loading the file.
> Backround: This can save a lot of disk space as the filled polygons
> tend to create a lot of points and tend to completely change with tiny
> changes to other elements on the board, such as a moved via. This
> means that version control has to store huge changes every time and it
> is hard to see what actual changes are happening just looking at the
> diff (I like to inspect diffs before checking something in, and this
> makes it hard. Also it makes it hard to git merge kicad-pcbs).
> Downside is, that everyone loading a file has to pay the extra cost to
> create the zones (e.g. gerber generation). Maybe it could be a
> heuristic to not store the filled polygons if recreating it takes less
> than a second or so.

Hi Henner,

I wouldn't change the file format for such purpose (I'm opposed to using
textual diff for graphical files, like PCBs). Also I don't think these
days saving a few megabytes is worth it.

Concerning the heuristics - It's a good idea, but for the moment I have
a ton of P&S issues to fix before the V5 goes out. Also I'm a bit
discouraged to write any GUI code after many failed attempts to update a
wxProgressDialog from an OpenMP context.

Tom



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Zone filling & display speed improvements

2017-12-05 Thread Tomasz Wlostowski
On 05/12/17 08:55, jp charras wrote:
> Le 05/12/2017 à 01:41, Tomasz Wlostowski a écrit :
>> Hi guys,
>>
>> Now it should work fine - the filling algorithm was not thread safe and
>> apparently wxProgressDialog can't be invoked from non-main thread.
>>
>> Check out the updated branch.
>>
>> Thanks!
>> Tom
>>
> 
> Hi Tom,
> 
> It works fine for me.
> And on my 4 cores computer, the speedup is really impressive!
> 
> Thanks.
> 

Hi guys,

Thanks for testing, I just merged it to the master.

Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Zone filling & display speed improvements

2017-12-05 Thread Oliver Walters
Tom,

Could the filling progress be displayed in the lower statusbar instead of a
popup window?

On Tue, Dec 5, 2017 at 2:48 PM, Henner Zeller  wrote:

> On 4 December 2017 at 16:41, Tomasz Wlostowski
>  wrote:
> > On 04/12/17 15:43, Henner Zeller wrote:
> >> On 4 December 2017 at 06:31, Tomasz Wlostowski
> >>  wrote:
> >>> On 04/12/17 02:05, Henner Zeller wrote:
>  On 2 December 2017 at 10:11, Henner Zeller  wrote:
> > On 1 December 2017 at 08:12, Tomasz Wlostowski
> >  wrote:
> >> On 29/11/17 16:10, jp charras wrote:
> >>> I am using a few board in Kicad demos: interf_u, video,
> pic_programmer.
> >>>
> >>> Also, filled areas are no shown in OpenGL, but are shown in Cairo
> canvas.
> >>
> >> Hi all,
> >>
> >> The branch [1] contains a set of improvements in the zone filling
> >> algorithm. It's several times faster than in the current master
> branch.
> >>
> >> I'd like to merge it soon and move on to fixing P&S issues pending
> for
> >> the V5 - I'll greatly appreciate testing and feedback!
> >
> > Hi Tom,
> >
> > I'll compile your branch hopefully later this weekend for testing.
> > If you need another board for testing, I am currently having a board
> > that takes annoying several seconds to fill the zones in head KiCad,
> > which hence might be interesting test case:
> >>>
> >>> Hi Henner,
> >>>
> >>> What OS did you build for?
> >>
> >> This was on Debian testing on a x86_64 machine.
> >> g++ 7.2.0, Cairo: 1.15.8, boost 1.62.0
> >>
> >> -h
> >
> > Hi guys,
> >
> > Now it should work fine - the filling algorithm was not thread safe and
> > apparently wxProgressDialog can't be invoked from non-main thread.
> >
> > Check out the updated branch.
>
> Thanks Tom!
>
> Nice, the [tom-faster-zones-dec01] branch works well and very fast. I
> have not seen any crashes anymore.
>
> There is a leftover method mentioned in pcbnew/class_zone.h:
>   void RemoveInsulatedCopperIslands()
> .. which is not used/implemented so should be removed from the header.
>
> One thing I noticed: since it is sooo fast now, the progress-popup is
> actually quite annoying as it just briefly blinks up and vanishes
> again (at least for the board I was testing it with). Maybe it should
> only show up if the operation is still ongoing after a second and less
> than 50% is done at that time ?
>
> Another thought: if zone filling can be that fast, maybe we should
> only store zone outlines in the *.kicad_pcb file, not the
> (filled_polygon ...) that are now also stored. It is cheap to just
> recreate them when loading the file.
> Backround: This can save a lot of disk space as the filled polygons
> tend to create a lot of points and tend to completely change with tiny
> changes to other elements on the board, such as a moved via. This
> means that version control has to store huge changes every time and it
> is hard to see what actual changes are happening just looking at the
> diff (I like to inspect diffs before checking something in, and this
> makes it hard. Also it makes it hard to git merge kicad-pcbs).
> Downside is, that everyone loading a file has to pay the extra cost to
> create the zones (e.g. gerber generation). Maybe it could be a
> heuristic to not store the filled polygons if recreating it takes less
> than a second or so.
>
> Cheers,
>   Henner.
>
> >
> > Thanks!
> > Tom
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Zone filling & display speed improvements

2017-12-05 Thread Heikki Pulkkinen
Hi,

Glad to hear, that my idea of parallel zone filling is working.


Regards

Heikki


On Tue, Dec 5, 2017 at 9:55 AM, jp charras  wrote:

> Le 05/12/2017 à 01:41, Tomasz Wlostowski a écrit :
> > Hi guys,
> >
> > Now it should work fine - the filling algorithm was not thread safe and
> > apparently wxProgressDialog can't be invoked from non-main thread.
> >
> > Check out the updated branch.
> >
> > Thanks!
> > Tom
> >
>
> Hi Tom,
>
> It works fine for me.
> And on my 4 cores computer, the speedup is really impressive!
>
> Thanks.
>
> --
> Jean-Pierre CHARRAS
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Zone filling & display speed improvements

2017-12-04 Thread jp charras
Le 05/12/2017 à 01:41, Tomasz Wlostowski a écrit :
> Hi guys,
> 
> Now it should work fine - the filling algorithm was not thread safe and
> apparently wxProgressDialog can't be invoked from non-main thread.
> 
> Check out the updated branch.
> 
> Thanks!
> Tom
> 

Hi Tom,

It works fine for me.
And on my 4 cores computer, the speedup is really impressive!

Thanks.

-- 
Jean-Pierre CHARRAS

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Zone filling & display speed improvements

2017-12-04 Thread Andrey Kuznetsov
Stay consistent, no heuristics for formats.
If it's slow on your machine, that doesn't mean it won't be fast on mine,
and you other points about version control make sense.
Do not store things like this, makes it hard on checkin.

On Mon, Dec 4, 2017 at 7:48 PM, Henner Zeller  wrote:

> On 4 December 2017 at 16:41, Tomasz Wlostowski
>  wrote:
> > On 04/12/17 15:43, Henner Zeller wrote:
> >> On 4 December 2017 at 06:31, Tomasz Wlostowski
> >>  wrote:
> >>> On 04/12/17 02:05, Henner Zeller wrote:
>  On 2 December 2017 at 10:11, Henner Zeller  wrote:
> > On 1 December 2017 at 08:12, Tomasz Wlostowski
> >  wrote:
> >> On 29/11/17 16:10, jp charras wrote:
> >>> I am using a few board in Kicad demos: interf_u, video,
> pic_programmer.
> >>>
> >>> Also, filled areas are no shown in OpenGL, but are shown in Cairo
> canvas.
> >>
> >> Hi all,
> >>
> >> The branch [1] contains a set of improvements in the zone filling
> >> algorithm. It's several times faster than in the current master
> branch.
> >>
> >> I'd like to merge it soon and move on to fixing P&S issues pending
> for
> >> the V5 - I'll greatly appreciate testing and feedback!
> >
> > Hi Tom,
> >
> > I'll compile your branch hopefully later this weekend for testing.
> > If you need another board for testing, I am currently having a board
> > that takes annoying several seconds to fill the zones in head KiCad,
> > which hence might be interesting test case:
> >>>
> >>> Hi Henner,
> >>>
> >>> What OS did you build for?
> >>
> >> This was on Debian testing on a x86_64 machine.
> >> g++ 7.2.0, Cairo: 1.15.8, boost 1.62.0
> >>
> >> -h
> >
> > Hi guys,
> >
> > Now it should work fine - the filling algorithm was not thread safe and
> > apparently wxProgressDialog can't be invoked from non-main thread.
> >
> > Check out the updated branch.
>
> Thanks Tom!
>
> Nice, the [tom-faster-zones-dec01] branch works well and very fast. I
> have not seen any crashes anymore.
>
> There is a leftover method mentioned in pcbnew/class_zone.h:
>   void RemoveInsulatedCopperIslands()
> .. which is not used/implemented so should be removed from the header.
>
> One thing I noticed: since it is sooo fast now, the progress-popup is
> actually quite annoying as it just briefly blinks up and vanishes
> again (at least for the board I was testing it with). Maybe it should
> only show up if the operation is still ongoing after a second and less
> than 50% is done at that time ?
>
> Another thought: if zone filling can be that fast, maybe we should
> only store zone outlines in the *.kicad_pcb file, not the
> (filled_polygon ...) that are now also stored. It is cheap to just
> recreate them when loading the file.
> Backround: This can save a lot of disk space as the filled polygons
> tend to create a lot of points and tend to completely change with tiny
> changes to other elements on the board, such as a moved via. This
> means that version control has to store huge changes every time and it
> is hard to see what actual changes are happening just looking at the
> diff (I like to inspect diffs before checking something in, and this
> makes it hard. Also it makes it hard to git merge kicad-pcbs).
> Downside is, that everyone loading a file has to pay the extra cost to
> create the zones (e.g. gerber generation). Maybe it could be a
> heuristic to not store the filled polygons if recreating it takes less
> than a second or so.
>
> Cheers,
>   Henner.
>
> >
> > Thanks!
> > Tom
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Zone filling & display speed improvements

2017-12-04 Thread Henner Zeller
On 4 December 2017 at 16:41, Tomasz Wlostowski
 wrote:
> On 04/12/17 15:43, Henner Zeller wrote:
>> On 4 December 2017 at 06:31, Tomasz Wlostowski
>>  wrote:
>>> On 04/12/17 02:05, Henner Zeller wrote:
 On 2 December 2017 at 10:11, Henner Zeller  wrote:
> On 1 December 2017 at 08:12, Tomasz Wlostowski
>  wrote:
>> On 29/11/17 16:10, jp charras wrote:
>>> I am using a few board in Kicad demos: interf_u, video, pic_programmer.
>>>
>>> Also, filled areas are no shown in OpenGL, but are shown in Cairo 
>>> canvas.
>>
>> Hi all,
>>
>> The branch [1] contains a set of improvements in the zone filling
>> algorithm. It's several times faster than in the current master branch.
>>
>> I'd like to merge it soon and move on to fixing P&S issues pending for
>> the V5 - I'll greatly appreciate testing and feedback!
>
> Hi Tom,
>
> I'll compile your branch hopefully later this weekend for testing.
> If you need another board for testing, I am currently having a board
> that takes annoying several seconds to fill the zones in head KiCad,
> which hence might be interesting test case:
>>>
>>> Hi Henner,
>>>
>>> What OS did you build for?
>>
>> This was on Debian testing on a x86_64 machine.
>> g++ 7.2.0, Cairo: 1.15.8, boost 1.62.0
>>
>> -h
>
> Hi guys,
>
> Now it should work fine - the filling algorithm was not thread safe and
> apparently wxProgressDialog can't be invoked from non-main thread.
>
> Check out the updated branch.

Thanks Tom!

Nice, the [tom-faster-zones-dec01] branch works well and very fast. I
have not seen any crashes anymore.

There is a leftover method mentioned in pcbnew/class_zone.h:
  void RemoveInsulatedCopperIslands()
.. which is not used/implemented so should be removed from the header.

One thing I noticed: since it is sooo fast now, the progress-popup is
actually quite annoying as it just briefly blinks up and vanishes
again (at least for the board I was testing it with). Maybe it should
only show up if the operation is still ongoing after a second and less
than 50% is done at that time ?

Another thought: if zone filling can be that fast, maybe we should
only store zone outlines in the *.kicad_pcb file, not the
(filled_polygon ...) that are now also stored. It is cheap to just
recreate them when loading the file.
Backround: This can save a lot of disk space as the filled polygons
tend to create a lot of points and tend to completely change with tiny
changes to other elements on the board, such as a moved via. This
means that version control has to store huge changes every time and it
is hard to see what actual changes are happening just looking at the
diff (I like to inspect diffs before checking something in, and this
makes it hard. Also it makes it hard to git merge kicad-pcbs).
Downside is, that everyone loading a file has to pay the extra cost to
create the zones (e.g. gerber generation). Maybe it could be a
heuristic to not store the filled polygons if recreating it takes less
than a second or so.

Cheers,
  Henner.

>
> Thanks!
> Tom
>

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Zone filling & display speed improvements

2017-12-04 Thread Tomasz Wlostowski
On 04/12/17 15:43, Henner Zeller wrote:
> On 4 December 2017 at 06:31, Tomasz Wlostowski
>  wrote:
>> On 04/12/17 02:05, Henner Zeller wrote:
>>> On 2 December 2017 at 10:11, Henner Zeller  wrote:
 On 1 December 2017 at 08:12, Tomasz Wlostowski
  wrote:
> On 29/11/17 16:10, jp charras wrote:
>> I am using a few board in Kicad demos: interf_u, video, pic_programmer.
>>
>> Also, filled areas are no shown in OpenGL, but are shown in Cairo canvas.
>
> Hi all,
>
> The branch [1] contains a set of improvements in the zone filling
> algorithm. It's several times faster than in the current master branch.
>
> I'd like to merge it soon and move on to fixing P&S issues pending for
> the V5 - I'll greatly appreciate testing and feedback!

 Hi Tom,

 I'll compile your branch hopefully later this weekend for testing.
 If you need another board for testing, I am currently having a board
 that takes annoying several seconds to fill the zones in head KiCad,
 which hence might be interesting test case:
>>
>> Hi Henner,
>>
>> What OS did you build for?
> 
> This was on Debian testing on a x86_64 machine.
> g++ 7.2.0, Cairo: 1.15.8, boost 1.62.0
> 
> -h

Hi guys,

Now it should work fine - the filling algorithm was not thread safe and
apparently wxProgressDialog can't be invoked from non-main thread.

Check out the updated branch.

Thanks!
Tom


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Zone filling & display speed improvements

2017-12-04 Thread Henner Zeller
On 4 December 2017 at 06:31, Tomasz Wlostowski
 wrote:
> On 04/12/17 02:05, Henner Zeller wrote:
>> On 2 December 2017 at 10:11, Henner Zeller  wrote:
>>> On 1 December 2017 at 08:12, Tomasz Wlostowski
>>>  wrote:
 On 29/11/17 16:10, jp charras wrote:
> I am using a few board in Kicad demos: interf_u, video, pic_programmer.
>
> Also, filled areas are no shown in OpenGL, but are shown in Cairo canvas.

 Hi all,

 The branch [1] contains a set of improvements in the zone filling
 algorithm. It's several times faster than in the current master branch.

 I'd like to merge it soon and move on to fixing P&S issues pending for
 the V5 - I'll greatly appreciate testing and feedback!
>>>
>>> Hi Tom,
>>>
>>> I'll compile your branch hopefully later this weekend for testing.
>>> If you need another board for testing, I am currently having a board
>>> that takes annoying several seconds to fill the zones in head KiCad,
>>> which hence might be interesting test case:
>
> Hi Henner,
>
> What OS did you build for?

This was on Debian testing on a x86_64 machine.
g++ 7.2.0, Cairo: 1.15.8, boost 1.62.0

-h

>
> Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Zone filling & display speed improvements

2017-12-04 Thread Tomasz Wlostowski
On 04/12/17 02:05, Henner Zeller wrote:
> On 2 December 2017 at 10:11, Henner Zeller  wrote:
>> On 1 December 2017 at 08:12, Tomasz Wlostowski
>>  wrote:
>>> On 29/11/17 16:10, jp charras wrote:
 I am using a few board in Kicad demos: interf_u, video, pic_programmer.

 Also, filled areas are no shown in OpenGL, but are shown in Cairo canvas.
>>>
>>> Hi all,
>>>
>>> The branch [1] contains a set of improvements in the zone filling
>>> algorithm. It's several times faster than in the current master branch.
>>>
>>> I'd like to merge it soon and move on to fixing P&S issues pending for
>>> the V5 - I'll greatly appreciate testing and feedback!
>>
>> Hi Tom,
>>
>> I'll compile your branch hopefully later this weekend for testing.
>> If you need another board for testing, I am currently having a board
>> that takes annoying several seconds to fill the zones in head KiCad,
>> which hence might be interesting test case:

Hi Henner,

What OS did you build for?

Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Zone filling & display speed improvements

2017-12-03 Thread Henner Zeller
On 2 December 2017 at 10:11, Henner Zeller  wrote:
> On 1 December 2017 at 08:12, Tomasz Wlostowski
>  wrote:
>> On 29/11/17 16:10, jp charras wrote:
>>> I am using a few board in Kicad demos: interf_u, video, pic_programmer.
>>>
>>> Also, filled areas are no shown in OpenGL, but are shown in Cairo canvas.
>>
>> Hi all,
>>
>> The branch [1] contains a set of improvements in the zone filling
>> algorithm. It's several times faster than in the current master branch.
>>
>> I'd like to merge it soon and move on to fixing P&S issues pending for
>> the V5 - I'll greatly appreciate testing and feedback!
>
> Hi Tom,
>
> I'll compile your branch hopefully later this weekend for testing.
> If you need another board for testing, I am currently having a board
> that takes annoying several seconds to fill the zones in head KiCad,
> which hence might be interesting test case:
>
> https://github.com/hzeller/quadrigotion.git
> path tmc2660/tmc2660-quad.kicad_pcb

So I tested your branch with the board above and it seems to work
quickly iff it does not crash; but it crashes
often. Sometimes the first time, sometimes the second time doing a
zone-recalculation (Tested under Cairo)

I have not debugged the full reason, but it seems to happen when
deleting a SHAPE_POLY_SET, somewhere around

ZONE_CONTAINER::BuildFilledSolidAreasPolygons () at
pcbnew/zone_filling_algorithm.cpp:138

Even if it is made sure that m_smoothedPoly has a defined value at
construction time with e.g.

---
--- a/pcbnew/class_zone.h
+++ b/pcbnew/class_zone.h
@@ -739,7 +739,7 @@ private:
void buildFeatureHoleList( BOARD* aPcb, SHAPE_POLY_SET& aFeatures );

SHAPE_POLY_SET*   m_Poly;///< Outline of the zone.
-SHAPE_POLY_SET*   m_smoothedPoly;// Corner-smoothed
version of m_Poly
+SHAPE_POLY_SET*   m_smoothedPoly = nullptr;//
Corner-smoothed version of m_Poly
int   m_cornerSmoothingType;
unsigned int  m_cornerRadius;
--

it still crashes, possibly because the recursive deleting it might
attempt to delete some shared SHAPE_LINE_CHAIN in it ?
Running it with valgrind indicates some double-delete issue.

Making this explicitly leak in pcbnew/zone_filling_algorithm.cpp:138
by removing the 'delete' it does not crash, so there is definitely
some double-delete stuff going on.

( there is also a lot of
../src/generic/progdlgg.cpp(435): assert "value <= m_maximum" failed
in Update(): invalid progress valu
e [in thread 20c55700]
../src/gtk/gauge.cpp(95): assert "pos <= m_rangeMax" failed in
SetValue(): invalid value in wxGauge::SetValue() [in thread 20c55700]

going on when compiling in debug mode, but I don't know if that is
related/relevant
)

Then when that is 'worked around', there are other crashes later when
selecting ranom zones, this is a typical stack trace.

#8  0x7fffe886e539 in PROGRESS_REPORTER::SetMaxProgress
(this=0x5843f800, aMaxProgress=193)
   at common/widgets/progress_reporter.cpp:62
#9  0x7fffe870700d in CN_CONNECTIVITY_ALGO::searchConnections
(this=0x572bfd00,
   aIncludeZones=true) at pcbnew/connectivity_algo.cpp:520
#10 0x7fffe87076db in CN_CONNECTIVITY_ALGO::SearchClusters
(this=0x572bfd00,
   aMode=CN_CONNECTIVITY_ALGO::CSM_RATSNEST, aTypes=0x57ce68e0,
aSingleNet=-1)
   at pcbnew/connectivity_algo.cpp:632
#11 0x7fffe8707480 in CN_CONNECTIVITY_ALGO::SearchClusters
(this=0x572bfd00,
   aMode=CN_CONNECTIVITY_ALGO::CSM_RATSNEST)
   at pcbnew/connectivity_algo.cpp:616
#12 0x7fffe8709243 in CN_CONNECTIVITY_ALGO::GetClusters
(this=0x572bfd00)
   at pcbnew/connectivity_algo.cpp:906
#13 0x7fffe86f77f5 in CONNECTIVITY_DATA::RecalculateRatsnest
(this=0x58052e70)
   at pcbnew/connectivity_data.cpp:147
#14 0x7fffe86a0f20 in BOARD_COMMIT::Push (this=0x57ce6c40,
aMessage=...,
   aCreateUndoEntry=false) at pcbnew/board_commit.cpp:281
#15 0x7fffe851ad18 in PCB_EDIT_FRAME::Fill_Zone
(this=0x56e0a4d0, aZone=0x5811f300)
   at pcbnew/zones_by_polygon_fill_functions.cpp:123
#16 0x7fffe8546577 in POINT_EDITOR::finishItem (this=0x587035f0)
   at pcbnew/tools/point_editor.cpp:575
#17 0x7fffe854535c in POINT_EDITOR::OnSelectionChange
(this=0x587035f0, aEvent=...)
   at pcbnew/tools/point_editor.cpp:379

Hope this is some useful input,
Henner.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Zone filling & display speed improvements

2017-12-02 Thread Henner Zeller
On 1 December 2017 at 08:12, Tomasz Wlostowski
 wrote:
> On 29/11/17 16:10, jp charras wrote:
>> I am using a few board in Kicad demos: interf_u, video, pic_programmer.
>>
>> Also, filled areas are no shown in OpenGL, but are shown in Cairo canvas.
>
> Hi all,
>
> The branch [1] contains a set of improvements in the zone filling
> algorithm. It's several times faster than in the current master branch.
>
> I'd like to merge it soon and move on to fixing P&S issues pending for
> the V5 - I'll greatly appreciate testing and feedback!

Hi Tom,

I'll compile your branch hopefully later this weekend for testing.
If you need another board for testing, I am currently having a board
that takes annoying several seconds to fill the zones in head KiCad,
which hence might be interesting test case:

https://github.com/hzeller/quadrigotion.git
path tmc2660/tmc2660-quad.kicad_pcb

Cheers,
  Henner.

>
> Tom
>
> [1] https://github.com/twlostow/kicad-dev/tree/tom-faster-zones-dec01
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Zone filling & display speed improvements

2017-12-02 Thread jp charras
Le 02/12/2017 à 17:49, Tomasz Wlostowski a écrit :
> On 02/12/17 17:33, jp charras wrote:
>> Le 01/12/2017 à 18:29, jp charras a écrit :
>>> Le 01/12/2017 à 17:12, Tomasz Wlostowski a écrit :
 On 29/11/17 16:10, jp charras wrote:
> I am using a few board in Kicad demos: interf_u, video, pic_programmer.
>
> Also, filled areas are no shown in OpenGL, but are shown in Cairo canvas.

 Hi all,

 The branch [1] contains a set of improvements in the zone filling
 algorithm. It's several times faster than in the current master branch.

 I'd like to merge it soon and move on to fixing P&S issues pending for
 the V5 - I'll greatly appreciate testing and feedback!

 Tom

 [1] https://github.com/twlostow/kicad-dev/tree/tom-faster-zones-dec01

>>>
>>> Hi Tom,
>>>
>>> I just tested this version on W7/32bits, msys2.
>>>
>>> No change since my previous test:
>>> It does not compile without my patch (please apply my patch)
>>> It hangs on refilling zones with any board (and even with no board, just 
>>> after created a single
>>> copper zone)
>>>
>>> Cheers,
>>>
>>
>> Hi Tom,
>> I made more tests:
>> Looks like hanging is due to open_mp use.
>>
>> When I disable open_mp, refilling zones works fine, and is very fast.
>>
> 
> Hi JP,
> 
> Thanks for the report, I'll try to investigate the OpenMP windows issues
> as soon as I'll manage to compile a Windows Kicad build :)
> 
> Cheers,
> Tom
> 

Thanks Tom.
Exactly, this is the refresh of the progress bar called inside a OpenMP  loop 
that hangs
( or any call to display something, for instance a wxMessageBox).

If removed, it runs very fast.
However I had a crash when refilling your complex board coming from a 
conversion from Altium.

Cheers

-- 
Jean-Pierre CHARRAS

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Zone filling & display speed improvements

2017-12-02 Thread Tomasz Wlostowski
On 02/12/17 17:33, jp charras wrote:
> Le 01/12/2017 à 18:29, jp charras a écrit :
>> Le 01/12/2017 à 17:12, Tomasz Wlostowski a écrit :
>>> On 29/11/17 16:10, jp charras wrote:
 I am using a few board in Kicad demos: interf_u, video, pic_programmer.

 Also, filled areas are no shown in OpenGL, but are shown in Cairo canvas.
>>>
>>> Hi all,
>>>
>>> The branch [1] contains a set of improvements in the zone filling
>>> algorithm. It's several times faster than in the current master branch.
>>>
>>> I'd like to merge it soon and move on to fixing P&S issues pending for
>>> the V5 - I'll greatly appreciate testing and feedback!
>>>
>>> Tom
>>>
>>> [1] https://github.com/twlostow/kicad-dev/tree/tom-faster-zones-dec01
>>>
>>
>> Hi Tom,
>>
>> I just tested this version on W7/32bits, msys2.
>>
>> No change since my previous test:
>> It does not compile without my patch (please apply my patch)
>> It hangs on refilling zones with any board (and even with no board, just 
>> after created a single
>> copper zone)
>>
>> Cheers,
>>
> 
> Hi Tom,
> I made more tests:
> Looks like hanging is due to open_mp use.
> 
> When I disable open_mp, refilling zones works fine, and is very fast.
> 

Hi JP,

Thanks for the report, I'll try to investigate the OpenMP windows issues
as soon as I'll manage to compile a Windows Kicad build :)

Cheers,
Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Zone filling & display speed improvements

2017-12-02 Thread jp charras
Le 01/12/2017 à 18:29, jp charras a écrit :
> Le 01/12/2017 à 17:12, Tomasz Wlostowski a écrit :
>> On 29/11/17 16:10, jp charras wrote:
>>> I am using a few board in Kicad demos: interf_u, video, pic_programmer.
>>>
>>> Also, filled areas are no shown in OpenGL, but are shown in Cairo canvas.
>>
>> Hi all,
>>
>> The branch [1] contains a set of improvements in the zone filling
>> algorithm. It's several times faster than in the current master branch.
>>
>> I'd like to merge it soon and move on to fixing P&S issues pending for
>> the V5 - I'll greatly appreciate testing and feedback!
>>
>> Tom
>>
>> [1] https://github.com/twlostow/kicad-dev/tree/tom-faster-zones-dec01
>>
> 
> Hi Tom,
> 
> I just tested this version on W7/32bits, msys2.
> 
> No change since my previous test:
> It does not compile without my patch (please apply my patch)
> It hangs on refilling zones with any board (and even with no board, just 
> after created a single
> copper zone)
> 
> Cheers,
> 

Hi Tom,
I made more tests:
Looks like hanging is due to open_mp use.

When I disable open_mp, refilling zones works fine, and is very fast.

-- 
Jean-Pierre CHARRAS

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Zone filling & display speed improvements

2017-12-01 Thread jp charras
Le 01/12/2017 à 17:12, Tomasz Wlostowski a écrit :
> On 29/11/17 16:10, jp charras wrote:
>> I am using a few board in Kicad demos: interf_u, video, pic_programmer.
>>
>> Also, filled areas are no shown in OpenGL, but are shown in Cairo canvas.
> 
> Hi all,
> 
> The branch [1] contains a set of improvements in the zone filling
> algorithm. It's several times faster than in the current master branch.
> 
> I'd like to merge it soon and move on to fixing P&S issues pending for
> the V5 - I'll greatly appreciate testing and feedback!
> 
> Tom
> 
> [1] https://github.com/twlostow/kicad-dev/tree/tom-faster-zones-dec01
> 

Hi Tom,

I just tested this version on W7/32bits, msys2.

No change since my previous test:
It does not compile without my patch (please apply my patch)
It hangs on refilling zones with any board (and even with no board, just after 
created a single
copper zone)

Cheers,

-- 
Jean-Pierre CHARRAS

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Zone filling & display speed improvements

2017-12-01 Thread Tomasz Wlostowski
On 29/11/17 16:10, jp charras wrote:
> I am using a few board in Kicad demos: interf_u, video, pic_programmer.
> 
> Also, filled areas are no shown in OpenGL, but are shown in Cairo canvas.

Hi all,

The branch [1] contains a set of improvements in the zone filling
algorithm. It's several times faster than in the current master branch.

I'd like to merge it soon and move on to fixing P&S issues pending for
the V5 - I'll greatly appreciate testing and feedback!

Tom

[1] https://github.com/twlostow/kicad-dev/tree/tom-faster-zones-dec01

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp