kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 10/22/2018 10:55 AM, Mark Roszko wrote:
>>I'd rather have the view, tools and core frameworks independent from
> any UI toolkit. 
>   Yes! Things change. The world develops as KiCad develops as well.
> Building into QT heavily just like wxWidgets could have the same
> ramifications later on if Qt ever fell out of favor.
> Or QT decides to change the API because that's what they do (clearly to
> justify their commerical support hehe ). Not to mention qt5 distro
> versions have the same mess as wxWidgets but perhaps even worse with qt5
> as it iterates versions faster than wx by a wide margin.

Sounds like this fall under the category of "be careful what you wish
for, you might get it".

> 
> 
> On Mon, Oct 22, 2018 at 10:30 AM Tomasz Wlostowski
> <tomasz.wlostowski@xxxxxxx <mailto:tomasz.wlostowski@xxxxxxx>> 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!
> 
>     Best,
>     Tom
> 
>     _______________________________________________
>     Mailing list: https://launchpad.net/~kicad-developers
>     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~kicad-developers
>     More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> -- 
> Mark
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>