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. > > Then again, while I know the internals of Kicad pretty well I know almost > nothing about OpenGL, so take this with a grain of salt. > > Cheers, > Jeff. > > >> On 24 Oct 2018, at 07:39, Michael Steinberg <michste...@gmail.com> wrote: >> >> Hello, >> >> it might perhaps be worthwile to add Pixel-Snapping to the vertex/geometry >> shader, depending on the introduced relative error. Of course pixel snapping >> geometry is always altering reality in favor of "clean" graphics, but if the >> error is reasonably small, it's mostly the ERC that needs to do it >> correctly, right? >> >> Michael >> >> >> Am 22.10.2018 um 16:29 schrieb Tomasz Wlostowski: >>> On 21/10/2018 14:35, Vesa Solonen wrote: >>>> Hi >>>> >>>> After testing the new OpenGL renderer on Eeschema I did some comparisons >>>> and tried to find ways for improvement. The speed improvement is >>>> enormous as expected. Thanks! >>> Hi Vesa, >>> >>> Thank you. >>>> The attached screenshot compares Eeschema and Gschem rendering of >>>> similar features. It is clear that Gschem grid fits everything on pixel >>>> centres and pushes the rounding error to "white space". Everything but >>>> grid fit lines is anti-aliased and nothing is scaled after rasterisation. >>>> In general MSAA is not good for anti-aliasing of line drawing vector >>>> source data. With vectors the AA is part of the rasterisation, not >>>> something to do afterwards as the group of pixels that resulted from >>>> rasterisation have already lost the meaning what they were about to >>>> represent, so the quality is lost. Especially pixel grid fitting is lost >>>> on scaling that shows as fuzzy lines in the example. >>> In general, OpenGL (or any other 3D API) is not good for drawing complex >>> 2D antialiased graphics *without* blending artifacts and with correct >>> layer ordering. When we designed GAL, we considered several options with >>> Orson: >>> - per-primitive shader-based antialiasing (as you suggested in your >>> first link). This is OK if you have no transparent objects to draw >>> (otherwise, it's difficult to avoid blending artifacts on overlapping >>> transparent objects on the same layer). >>> - the solution above with per-layer pixel/stencil buffer to avoid >>> artifacts, which is expensive in terms of raster operations (lots of >>> overdraw to composite the layers on top of each other) >>> - Native HW accelerated 2D graphics API, dropped because of lack of >>> standardization and large effort to support different 2D libraries on >>> multiple platforms. >>> - Z buffering with MSAA/SSAA. Its advantages are correct blending and >>> speed (especially for MSAA), at the price of some artifacts produced by >>> the MSAA algorithm. >>> >>> We chose the last option, as the speed is most important in a CAE >>> program view. For the time being you can either enable 4x supersampling >>> (if you have an $80+ graphics card I bet it'll work lightning fast) or >>> dig out the old antialiased Cairo GAL from the repo. We removed it from >>> pcbnew 2 years ago because it was unusably slow, but it provided >>> beautifully antialiased and correctly blended images. >>> >>> >>>> I also remember the ocassional talk about Qt and by the effort that goes >>>> to working around wx bugs and non-features something else could be done >>>> on Qt. >>> I'd rather have the view, tools and core frameworks independent from any >>> UI toolkit. >>> >>>> The OpenGL accelerated QPainter is pretty convincing these days. >>> Does it support layers and artifact-free transparency? Last time I >>> checked it didn't. Some proprietary EDA tools I know use QGraphicsView >>> and the graphics are neither very fast nor look good. But maybe things >>> have changed... >>> >>>> Instead of deepfakes the wx to Qt porting AI would be more productive... >>> I think using QPainter/QGraphicsView mixed with Kicad tool/view code >>> base is as bad as doing this with any other UI library. >>> >>> On the other hand, Qt for the UI part of Kicad looks *very* interesting! >>> >>> Best, >>> Tom >>> >>> _______________________________________________ >>> 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 >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 > _______________________________________________ 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
