Tomasz Wlostowski kirjoitti 24.10.2018 klo 17.04: > On 24/10/2018 13:32, Jeff Young wrote: >> If the pixel snapping happens in the shader then ERC wouldn’t know about it. >> We just have to make sure that the snap direction is uniform so we don’t >> end up with visual mismatches between wires & pins (for instance). > > I'll have a look at it. > > T.
The pixel fitting has to be applied to global coordinate system as it is scaled to display and back, not just per item. I had a brief discussion with Gschem renderer author when the thing was new, somewhere between 2008–2012. He used some neat tricks, so maybe have a look at the code. Some hopefully related links follow: [1] https://github.com/rougier/gl-agg [2] http://jcgt.org/published/0002/02/08/paper.pdf [3] http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-98-2.pdf [4] https://github.com/memononen/nanovg [5] https://www.shadertoy.com/view/ltcBzj [6] http://vispy.org/ After playing with the last one and GnuRadio my impression is that Python_guitoolkitofchoice, OpenGL view, and C++ processing might be the most productive combo regarding lines of code, performance and developer base. If we are providing a python (GUI) scripting interface anyway, why not draw the slow main menus and GUI buttons as well? -Vesa _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
