kicad-developers team mailing list archive
Mailing list archive
Re: Kicad's way of drawing filled zones
Forgive me if this is what the 'boolean sum' option is, and I'm not
familiar with the GL Api itself, but:
Would a possibility be to focus purely on the Vias for the moment, given
how many there are:
- render the via outline using a rectangular texture with transparent
- render the via hole in the zone as a simple square, side length = via
diameter, and underneath the texture, so the texture's curve fills in
the square's corners?
On 11/05/2019 12:06, jp charras wrote:
Le 10/05/2019 à 18:33, Tomasz Wlostowski a écrit :
I've been recently playing with Victor's huge 32-layer PCB design and
trying to improve the performance of pcbnew for larger designs. This
board causes even pretty decent PCs to crash/render glitches due to
pcbnew's enormous VBO (Vertex Buffer) memory consumption.
It turns out it's caused by the way KiCad renders filled zones:
- the inside of a zone is drawn/plotted as a filled polygon with 0-width
boundary. This one not a problem - we already triangulate the polygons
and I recently developed a patch for the OpenGL GAL that allows reusing
vertices of triangulated polys in the VBO/Index buffer to further reduce
- the thick outline is drawn with rounded segments with the width =
minimum width of the polygon. Since we don't have arcs in polygons, each
of round features (e.g. vias) surrounded by a zone gets a ton of tiny
segments in the polygon outline. Each rounded segment in OpenGL is
composed of 2 triangles, hence 6 vertices (that can't be reused...). For
Victor's board it means 1 GB (sic!) of the VBO goes for outlines of the
polygons alone. Disabling the outline drawing makes the renderer work
I've been experimenting with some ways to fix this:
- generating the thick outline strokes using a Geometry Shader (which
means bumping up GL 3.0+), which means farewell to many Linux/older
integrated Graphics users.
- caching a triangulated polygon which is a boolean sum of the filled
inside and the thick stroked outline. This takes a lot of time (~2
minutes for Victor's design) to load and still takes quite a bit of VBO
memory. Another downside is that the polygons are not fully WYSIWYG
(outline segments have true rounded corners, while the corners of the
displayed shape would be approximated with line segments).
- change the way KiCad handles filled zones to calculate the (stroke +
inside) boolean sum during zone filling process. It means changes to the
plotting/GAL/3D code, but no changes to the file format. We'll also be
forced to inform the users that they have to refill the zones if they
read a file generated by an older KiCad version.
Which solution would you prefer?
I have a *strong preference* for the solution 3:
- It does not require a bumping to GL 3.0. I am not thrilled by this idea.
- It works also in Cairo engine.
- It fixes a issue in connection calculations: a connection (pad, via
track end) is found if the reference position is inside the zone.
Inside the zone is currently inside the main polygon, not really the
full area (polygon+thick outline), so a few connections are missed.
Why I have used polygons with thick outlines:
Because the polygon library used at this time did not a good job to
inflate polygons (read a really bad job).
But this is not the case now with Clipper, that is a really great
I made a very fast test, and just tried these 2 changes:
- do not draw thick outlines
- Use 16 segments by circle to create holes and polygon inflate: this is
enough for this purpose. I am not sure other ECADs are better.
- and inflate the filled polygons by zone min thickness/2
the result is very good:
- filled polygon shapes are very good.
- the number of segments to draw filled polygons does not significantly
Of course, using segments to draw thick outlines give a better look for
acute angles, but do not mix cosmetic criteria and technical criteria.