kicad-developers team mailing list archive
Mailing list archive
Re: Kicad's way of drawing filled zones
KiCad Developers <kicad-developers@xxxxxxxxxxxxxxxxxxx>
jp charras <jp.charras@xxxxxxxxxx>
Sat, 11 May 2019 16:32:43 +0200
Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
Le 11/05/2019 à 16:18, Jon Evans a écrit :
> Hi JP,
> Thanks for the input, it's a good point. It sounds like in this case
> there may be a technical solution that works fine in GL2.1 so I agree it
> makes sense to avoid raising requirements if at all possible.
> Do you have any thoughts about how we should handle this in the future,
> if for some reason there is a technical challenge that cannot be solved
> as easily without moving to a higher OpenGL version? (or some other
> similar hardware support issue) Should we always design for 2.1, or is
> there some time in the future when it becomes appropriate to expect
> users to have something newer?
Of course, if OpenGL 2.1 cannot solve a technical challenge, we can move
Moreover, in the future, more PCs will support 3.0.
However, generally speaking, I prefer better algorithms to more powerful
> On Sat, May 11, 2019, 07:27 jp charras <jp.charras@xxxxxxxxxx
> <mailto:jp.charras@xxxxxxxxxx>> wrote:
> Le 10/05/2019 à 18:43, Jon Evans a écrit :
> > Does anyone have a good sense of which hardware / software platforms
> > would be impacted by a switch to OpenGL 3.0 as baseline requirement?
> > As far as I am aware, all commercial tools in the space have more
> > advanced / modern system requirements than KiCad, with the possible
> > exception of Eagle. We have to consider whether supporting old
> > graphics cards goes counter to the desire to have KiCad handle more
> > professional use cases (including large designs).
> > The integrated Intel GPUs that are old enough to not have OpenGL
> 3.0 are
> > no longer supported by Intel (everything since HD2000 series has
> it, as
> > far as I know)
> > -Jon
> Hi Jon,
> To be honest, I do not share your opinion, and I am not especially
> thrilled by switching to OpenGL 3.0 as baseline requirement as long as
> we can avoid it.
> OpenGL 2.1 is a reasonable requirement.
> What is a professional use case?
> I know at least 2 opposite cases:
> - A advanced user who designs very complex boards: he needs a recent and
> fast computer with 2 (or enev 3) monitors.
> - Classroom "users"
> They are also professional users who do not design very complex boards.
> But force updating the computers just to use Kicad is a serious issue:
> As a old teacher I am knowing what I am saying:
> In the department I worked before being retired, we have roughly 200 PCs
> (most of them are dual boot: Linux and Windows).
> Not of all are used to run Kicad, but many of them.
> Saying: our new Kicad version needs a recent computer+OS so you have to
> change 50 or 100 of your computers in a bit hard for these users.
> > On Fri, May 10, 2019, at 12:33 PM, Tomasz Wlostowski wrote:
> >> Hi,
> >> 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
> >> boundary. This one not a problem - we already triangulate the
> >> and I recently developed a patch for the OpenGL GAL that allows
> >> vertices of triangulated polys in the VBO/Index buffer to further
> >> memory footprint.
> >> - 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
> >> smooth again.
> >> 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?
> >> Cheers,
> >> Tom