kicad-developers team mailing list archive

[Vesa Solonen <vsolonen@...>]

The following contains some previous discussion pulled from private to
the list. All the interesting parts are along.

ti, 2008-11-25 kello 21:16 +0100, jean-pierre.charras@... kirjoitti:
> Vesa Solonen a écrit :

> > I'd like to suggest changing arc approximation to use 20 and 40
> > segments as 3600/32 is not even and it makes some of the drawing
> > defects. Also that would enable 80 segments use too, for shifting the
> > starting point 'half increment'. That way vertex points would be out
> > of line from component x or y and instead put edges there. The
> > benefit is more room for copper fills as adjacent vertex points would
> > be further apart by arc approximation error. I'll show an example
> > next time if my explanation is not understandable.
> >
> Increasing the number of segments in arc approximation can create 
> problems from a drawing time point of view.
> If you test the demo "video" you can seen the drawing time for a zone 
> built with 16 segments per circle is already a problem.
> Perhaps the best solution is an automatic recognition of arcs in 
> polygons outlines, and draw arcs insteed of segments.
> Segments will be used only in polygon calculations, and converted to 
> arcs after calculations to draw areas outlines
> I am sure it is not very difficult to do that.
> this feature exists in GDSII viewer/editor (i believe) (by the author 
> of kbool) , and freePCB (i am sure).

Could someone give any advice how to profile the code? I've seen
examples that Boost stl's string operations are really slow compared to
even OS functions. Pity I can't find my reference. Anyway for those
vertex arrays stl vectors are used and algorithm is very iterative, so
some kind of refining is meeded before going to conclusion I think. Also
possibilities for SIMD vectorization should given a look at:

http://gcc.gnu.org/projects/tree-ssa/vectorization.html

I've played with it some times and it may give over ten times better
performance. My test was a dot product with short int and 256B vector
length. String compares should give about 4 to 8 times enhancements.
Especially newer cpus with sse4 instructions will make SIMD even easier
as they work without without aligned data too. Naturally it may be a bit
early to optimise stuff yet, but just to avoid complete rewrite for
optimization...

For arcs, does Gerber support arc-outlines or was your intention to
trace the outline with arcs and then coarse polygons with peak-to-peak
error inside that outline line?

I played with FreePCB on Wine and weren't able to view those gerbers on
Gerbview as they seem to use negative aperture data or then I messed
something up.

> > Per pin thermal orientation and automatic 'orphan' thermal bridge
> > cutting is on my wish list next ;) If you have time, please point me
> > to the small discrete pieces of code work to be done. Small and
> > discrete as I don't yet nkow the big picture well enough.
> >
> the bug in kbool must be solved before.
> I planed to create a file to show the problem i find ( an erroneous 
> polygon when calculating filled areas) and send it to the kbool's author.
> This problem can be seen with interf_u demo:
> with thermal reliefs with 0 orient on round pad , and thermal bridge = 
> 0.02", zone clearance = 0.015", you get no filled areas.
> Some others configurations also have problems.

I wish this gets sorted out soon :)

Oh, and I almost forgot to mention that local PCB-factory prefers to use
polygons for fills. My guess is that they need to plot tracks and every
small detail slower and with better focus than those polygon fills.

-Vesa