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