kicad-developers team mailing list archive

[jean-pierre charras - INPG <jean-pierre.charras@...>]

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 
> <mailto:jean-pierre.charras%40inpg.fr> 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 
> <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. ..

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 
24000 segments)

> 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?
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 
?) approach.
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),
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
> something up.
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 
> 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
>
> _

--
Jean-Pierre CHARRAS
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

Recherche :
Grenoble Image Parole Signal Automatique (GIPSA - INPG)
46, Avenue Félix Viallet
38031 Grenoble Cedex