kicad-developers team mailing list archive

[Andrey Kuznetsov <kandrey89@xxxxxxxxx>]

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 <h.zeller@xxxxxxx> wrote:

> On 4 December 2017 at 16:41, Tomasz Wlostowski
> <tomasz.wlostowski@xxxxxxx> wrote:
> > On 04/12/17 15:43, Henner Zeller wrote:
> >> On 4 December 2017 at 06:31, Tomasz Wlostowski
> >> <tomasz.wlostowski@xxxxxxx> wrote:
> >>> On 04/12/17 02:05, Henner Zeller wrote:
> >>>> On 2 December 2017 at 10:11, Henner Zeller <h.zeller@xxxxxxx> wrote:
> >>>>> On 1 December 2017 at 08:12, Tomasz Wlostowski
> >>>>> <tomasz.wlostowski@xxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> 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]

kandrey89@xxxxxxxxx
Live Long and Prosper,
Andrey