On 10/22/2018 10:29 AM, Tomasz Wlostowski wrote: > 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!
After v6 is released, we may want to take a closer look at Qt if the wxWidgets/wxPython situation doesn't significantly improve by then. I have no idea if python support for Qt is any better than wx so this just may be my frustration with the current situation. As for the UI stuff alone, I really don't have a preferences other than not spending an entire version development cycle just to change UI toolkits. > > 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
