kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

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?

Best,
Jon


On Sat, May 11, 2019, 07:27 jp charras <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 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
> >> 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
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >>
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
>
> --
> Jean-Pierre CHARRAS
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>