kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

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