kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

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? 
> 
> Best, 
> Jon

Of course, if OpenGL 2.1 cannot solve a technical challenge, we can move
to 3.0.

Moreover, in the future, more PCs will support 3.0.

However, generally speaking, I prefer better algorithms to more powerful
PCs.

> 
> 
> 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
>     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


-- 
Jean-Pierre CHARRAS