kicad-developers team mailing list archive
Mailing list archive
Re: Arc support in zones etc
jean-pierre charras - INPG <jean-pierre.charras@...>
Mon, 15 Dec 2008 12:43:22 +0100
Thunderbird 188.8.131.52 (Windows/20081105)
Vesa Solonen a écrit :
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@inpg. fr
> 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
I am thinking computation time (for drawings) is not at pcbnew level,
but at graphic layer level (wxWidgets ? or Windows/Xwindows)
drawing time grows faster than segments count:
On my computer: less than 1 second for 12000 segments, 5 seconds for
Yes i believe trace the outline with arcs and then coarse polygons with
peak-to-peak error inside that outline line is an interesting (the best
Arcs support has some advantages only when creating/editing complex
zones outlines, not to draw them.
Filling areas can be handle by polygons (therefore without any arc
outlines, not supported by GERBER or graphic polygon primitives),
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?
or by segments (these 2 ways are now supported by pcbnew)
FreePCB uses also zones outline to define the entire board shape (with
holes, restricted areas ...)
this is an interesting idea.
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
Yes, negative layers are used.
But most PCB manufacturers do not like this, because they cannot use DRC
at gerber level.
So i do not want to use negative layers in pcbnew.
(A negative layers support in Gerbview is a good thing, to allow display
of all gerber files, but use them in Pcbnew is a bad idea)
> > 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
> 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.
Maître de conférences
Directeur d'études 2ieme année.
Génie Electrique et Informatique Industrielle 2
Institut Universitaire de Technologie 1 de Grenoble
BP 67, 38402 St Martin d'Heres Cedex
Grenoble Image Parole Signal Automatique (GIPSA - INPG)
46, Avenue Félix Viallet
38031 Grenoble Cedex