kicad-developers team mailing list archive

["Magnus Beischer" <magnus@...>]

--- In kicad-devel@xxxxxxxxxxxxxxx, Dick Hollenbeck <dick@...> wrote:
>
> 
> I would not want to accept this patch, or any like it. However, we 
> could put it into the repository for future use.
> 
> My concern:
> Zone filling and drawing is way too slow now. This patch would affect 
> the basic drawing on screen of zones also I presume.
> 
> I have some very elaborate boards for which it takes 3 minutes to fill 
> zones even on a fast computer. It takes 2 seconds to draw these boards 
> on screen onces the zones rasters are in place, again on a fast
computer.
> 
> I cannot tolerate any slower zone drawings.
> 
> If and when we move the zone raster generation to the gerber generation 
> process/step, then an improvement like this would be worth considering.
> 
> Until then, perhaps the electrons will not complain about their 
> playground having a ragged fence around it.
> 
> 
> Dick

I guess that we have 2 separate speed problems here:
1) Generating the zone fill segments (done once for every zone)
2) Drawing the zone fill segments on screen (done all the time the
user move, zoom, redraw etc. on the screen.

Making changes that increase the drawing speed is not a good idea, but
I think a smarter sone fill algorithm could drastically speed up the
drawing on the screen. A question here for you Dick: If zone creation
time goes up by 20% and zone drawig on the screen goes down by 50%,
would you conider that to be an improvement? (if also generating
smother edges)

Magnus


> 
> > I wrote a small patch for starting to address this issue.
> > You can look at the results on this images, where the *_ORIG
images are 
> > generated using Kicad SVN 1241 and the corresponding *_SMOOTH
images are 
> > generated with the patched version. The board used for the
screenshots 
> > is pic_programmer.brd from the demos:
> >
> > http://www.naustech.com/kicad/test_1_ORIG.png
> > http://www.naustech.com/kicad/test_1_SMOOTH.png
> > http://www.naustech.com/kicad/test_2_ORIG.png
> > http://www.naustech.com/kicad/test_2_SMOOTH.png
> > http://www.naustech.com/kicad/test_3_ORIG.png
> > http://www.naustech.com/kicad/test_3_SMOOTH.png
> > http://www.naustech.com/kicad/test_4_ORIG.png
> > http://www.naustech.com/kicad/test_4_SMOOTH.png
> >
> > (Sorry, but I did not had the time to set up a proper html page :-) )
> >
> > What the patch basically does is to connect every start/end point
of a 
> > zone track to any other start/end point nearer than
'g_GridRoutingSize'
> >
> > If you find it useful, I can post the patch in few days (after
modifying 
> > it to obey Kicad coding standards).
> >
> > General considerations:
> >
> > - this is my first patch to Kicad, so be gentle... :-)
> >
> > - we can achieve good results with 45degree zones and with box-shaped 
> > regions
> >
> > - with circular regions (like the ones around pads and thermals) its 
> > difficult to say if the result is better (i.e. more
'professional') or 
> > worse then the unpatched version
> >
> > - pheraps we could achieve better results if we permit to the zone 
> > tracks to overlay for 1/2, like you can see in the images from 
> > http://beischer.com/opencad/fillzone.htm
> >
> > - it adds a lot of small tracks to the zone (I'll do more test to
figure 
> > out how many more in percentage)
> >
> > - it is quite slow, so it would be better to use this function only 
> > once, just before plotting the gerbers
> >
> > - as far as I can see, there should be no worries regarding wrong 
> > connections (i.e. connecting zones that should not be connected) if 
> > 'g_Grid_RoutingSize' is smaller then the clearance. I've run the DRC 
> > several times and with different fill grid sizes without finding any 
> > problem...
> >
> >
> > Best regards, Gabriele
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
>