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 : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > 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 : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
